Reference fixes

tutorials/optimization/using_multimesh.rst

@@ -5,7 +5,7 @@ Optimization Using Multimeshes
 
 For large amount of instances (in the thousands), that need to be constantly processed (and certain amount of control needs to be retained), :ref:`using servers directly<doc_using_servers>` is the recommended optimization.
 
-When the amount of objects reach the dozens of thousands, hundreds of thousands or even millions, none of these approaches are efficient any more. Still, depending on the requirements, there is one more optimization possible.
+When the amount of objects reach the dozens of thousands, hundreds of thousands or even millions, none of these approaches are efficient anymore. Still, depending on the requirements, there is one more optimization possible.
 
 
 Multimeshes
@@ -15,11 +15,11 @@ A :ref:`MultiMesh<class_MultiMesh>` is a single draw primitive that can draw up
 
 The only drawback is that there is no *screen* or *frustum* culling possible for individual instances. This means, that millions of objects will be *always* or *never* drawn, depending on the visibility of the whole MultiMesh. It is possible to provide a custom visibility rect for them, but it will always be *all-or-none* visibility.
 
-If the objects are simple enough (just a couple of vertices), this is generally not much of a problem as most modern GPUs are optimized for this use case.
+If the objects are simple enough (just a couple of vertices), this is generally not much of a problem as most modern GPUs are optimized for this use case. A workaround is to create several multimeshes for different areas of the world.
 
 If logic is too simple, it is also possible to execute it inside the vertex shader (using the INSTANCE_ID integer built-in constant). Information to it can be provided via textures (there are floating point :ref:`Image<class_Image>` formats which are ideal for this).
 
-Another alternative is to use GDNative and C++, which should be extremely efficient (it's possible to set the entire state for all objects using linear memory via the `VisualServer.multimesh_set_as_bulk_array()<class_VisualServer_method_multimesh_set_as_bulk_array>` function. This way, the array can be created with multiple threads, then set in one call, providing high cache efficiency.
+Another alternative is to use GDNative and C++, which should be extremely efficient (it's possible to set the entire state for all objects using linear memory via the :ref:`VisualServer.multimesh_set_as_bulk_array()<class_VisualServer_method_multimesh_set_as_bulk_array>` function. This way, the array can be created with multiple threads, then set in one call, providing high cache efficiency.
 
 Finally, it's not required to have all multimesh instances visible. The amount of visible ones can be controlled with the *MultiMesh.visible_instance_count* property. The typical workflow is to allocate the maximum amount of instances that will be used,
 then change the amount visible depending on how many are currently needed.

tutorials/optimization/using_servers.rst

@@ -3,7 +3,7 @@
 Optimization Using Servers
 ============
 
-Engines like Godot provide increased ease of use thanks to it's high level constructs and features. Most of them are accessed and used via the :ref:`Scene System<doc_scene_tree>`. Using nodes and resources simplify project organization and asset management
+Engines like Godot provide increased ease of use thanks to it's high level constructs and features. Most of them are accessed and used via the :ref:`Scene System<doc_scene_tree>`. Using nodes and resources simplifies project organization and asset management
 in complex games.
 
 There are, of course always drawbacks
@@ -15,9 +15,9 @@ There are, of course always drawbacks
 
 In far most cases, this is not really a problem (Godot is very optimized, and most operations are handled with signals, so no polling is required). Still, sometimes it may be. As an example, dealing with dozens of thousands of instances for something that needs to be processed every frame can pose a bottleneck. 
 
-This type of situation makes some programmers regret they are using a game engine and wish they could go back to a more handcrafted, low level implementation of game code. 
+This type of situation makes programmers regret they are using a game engine and wish they could go back to a more handcrafted, low level implementation of game code. 
 
-Still, Godot is designed to work around this problem too.
+Still, Godot is designed to work around this problem.
 
 Servers
 -------
@@ -31,23 +31,23 @@ At the core, Godot uses the concept of Servers. They are very low level APIs to
 * :ref:`Physics2DServer<class_Physics2DServer>` handles everything related to 2D physics.
 * :ref:`AudioServer<class_AudioServer>` handles everything related to audio.
 
-Just explore their API and you will realize that the all functions provided are low level implementations of everything Godot allows to do.
+Just explore their APIs and you will realize that the all functions provided are low level implementations of everything Godot allows to do.
 
 RIDs
 ----
 
 The key to using servers is understanding RID objects (RID means Resource ID). These are opaque handles to the sever implementation. They are allocated and freed manually. Almost every function in the servers requires RIDs to access the actual resource.
 
-Most Godot nodes and resources contain internally these RIDs from the servers, and they can be obtained with different functions. In fact, anything that inherits `Resource<class_Resource>` can be directly casted to an RID (not all resources contain an RID, though, in such cases the RID will be empty). In fact, resources can be passed to server APIs as RIDs. Just make sure to keep references to the resources ouside the server, because if the resource is erased, the internal RID is erased too.
+Most Godot nodes and resources contain internally these RIDs from the servers, and they can be obtained with different functions. In fact, anything that inherits :ref:`Resource<class_Resource>` can be directly casted to an RID (not all resources contain an RID, though, in such cases the RID will be empty). In fact, resources can be passed to server APIs as RIDs. Just make sure to keep references to the resources ouside the server, because if the resource is erased, the internal RID is erased too.
 
 For nodes, there are many functions available:
 
-* For CanvasItem, the `CanvasItem.get_canvas_item()<class_CanvasItem_method_get_canvas_item>` method will return the canvas item RID in the server. 
-* For CanvasLayer, the `CanvasLayer.get_canvas()<class_CanvasLayer_method_get_canvas>` method will return the canvas RID in the server. 
-* For Viewport, the `Viewport.get_viewport_rid()<class_Viewport_method_get_viewport_rid>` method will return the viewport RID in the server. 
-* For 3D, the `World<class_World>` resource (obtainable in the *Viewport* and *Spatial* nodes, contains function to get the *VisualServer Scenario*, and the *PhysicsServer Space*. This allows creating 3D objects directly with the server API and using them.
-* For 2D, the `World2D<class_World2D>` resource (obtainable in the *Viewport* and *CanvasItem* nodes, contains function to get the *VisualServer Canvas*, and the *Physics2DServer Space*. This allows creating 2D objects directly with the server API and using them.
-* The`VisualInstance<class_VisualInstance` class, allows getting the scenario *instance* and *instance base* via the `VisualInstance.get_instance()<class_VisualInstance_method_get_instance>` and `VisualInstance.get_base()<class_VisualInstance_method_get_base>` respectively.
+* For CanvasItem, the :ref:`CanvasItem.get_canvas_item()<class_CanvasItem_method_get_canvas_item>` method will return the canvas item RID in the server. 
+* For CanvasLayer, the :ref:`CanvasLayer.get_canvas()<class_CanvasLayer_method_get_canvas>` method will return the canvas RID in the server. 
+* For Viewport, the :ref:`Viewport.get_viewport_rid()<class_Viewport_method_get_viewport_rid>` method will return the viewport RID in the server. 
+* For 3D, the :ref:`World<class_World>` resource (obtainable in the *Viewport* and *Spatial* nodes, contains function to get the *VisualServer Scenario*, and the *PhysicsServer Space*. This allows creating 3D objects directly with the server API and using them.
+* For 2D, the :ref:`World2D<class_World2D>` resource (obtainable in the *Viewport* and *CanvasItem* nodes, contains function to get the *VisualServer Canvas*, and the *Physics2DServer Space*. This allows creating 2D objects directly with the server API and using them.
+* The :ref:`VisualInstance<class_VisualInstance` class, allows getting the scenario *instance* and *instance base* via the :ref:`VisualInstance.get_instance()<class_VisualInstance_method_get_instance>` and :ref:`VisualInstance.get_base()<class_VisualInstance_method_get_base>` respectively.
 
 Just explore the nodes and resources you are familiar with and find the functions to obtain the server *RIDs*. 
 
@@ -58,11 +58,12 @@ Creating a sprite
 
 This is a simple example of how to create a sprite from code and move it using the low level Canvas Item API.
 
-extends Node2D
 
 .. tabs::
  .. code-tab:: gdscript GDScript
 
+    extends Node2D
+
     func _ready():
 	
         # Create a canvas item, child of this node