Update tutorials: VisualServer to RenderingServer

tutorials/3d/procedural_geometry/arraymesh.rst

@@ -40,7 +40,7 @@ The third parameter is an array of blendshapes for the Mesh to use. While this t
 using blendshapes, it is possible to specify them when creating a surface from arrays.
 
 The last parameter is the compress flags which specifies which arrays to store with half as many bits. The
-values can be found in the classref for :ref:`VisualServer <class_visualserver>` under :ref:`ArrayFormat <enum_visualserver_arrayformat>`.
+values can be found in the classref for :ref:`RenderingServer <class_renderingserver>` under :ref:`ArrayFormat <enum_renderingserver_arrayformat>`.
 
 For normal usage you will find it is best to leave the last two parameters empty.
 

tutorials/3d/procedural_geometry/index.rst

@@ -52,7 +52,7 @@ What a Mesh is
 
 A Mesh is composed of one or more surfaces. A surface is an array composed of multiple sub-arrays
 containing vertices, normals, UVs, etc. Normally the process of constructing surfaces and meshes is
-hidden from the user in the :ref:`VisualServer <class_VisualServer>`, but with ArrayMeshes, the user can construct a Mesh
+hidden from the user in the :ref:`RenderingServer <class_RenderingServer>`, but with ArrayMeshes, the user can construct a Mesh
 manually by passing in an array containing the surface information.
 
 Surfaces

tutorials/best_practices/data_preferences.rst

@@ -317,7 +317,7 @@ Users can manipulate...
 
 2. the number of regions contained within the texture (frames).
 
-Godot's :ref:`VisualServer <class_VisualServer>` then draws
+Godot's :ref:`RenderingServer <class_RenderingServer>` then draws
 the regions in sequence at the prescribed rate. The good news is that this
 involves no extra logic on the part of the engine. The bad news is
 that users have very little control.

tutorials/io/background_loading.rst

@@ -213,7 +213,7 @@ Not blocking main thread during the polling
 If you have a mutex to allow calls from the main thread to your loader
 class, don't lock the main thread while you call ``poll`` on your loader class. When a
 resource is done loading, it might require some resources from the
-low-level APIs (VisualServer, etc), which might need to lock the main
+low-level APIs (RenderingServer, etc), which might need to lock the main
 thread to acquire them. This might cause a deadlock if the main thread
 is waiting for your mutex while your thread is waiting to load a
 resource.

tutorials/io/files/resource_queue.gd

@@ -81,7 +81,7 @@ func is_ready(path):
 func _wait_for_resource(res, path):
 	_unlock("wait_for_resource")
 	while true:
-		VisualServer.sync()
+		RenderingServer.force_sync()
 		OS.delay_usec(16000) # Wait approximately 1 frame.
 		_lock("wait_for_resource")
 		if queue.size() == 0 || queue[0] != res:

tutorials/performance/thread_safe_apis.rst

@@ -14,7 +14,7 @@ Below is a list of ways multithreading can be used in different areas of Godot.
 Global scope
 ------------
 
-:ref:`Global Scope<class_@GlobalScope>` singletons are all thread-safe. Accessing servers from threads is supported (for VisualServer and Physics servers, ensure threaded or thread-safe operation is enabled in the project settings!).
+:ref:`Global Scope<class_@GlobalScope>` singletons are all thread-safe. Accessing servers from threads is supported (for RenderingServer and Physics servers, ensure threaded or thread-safe operation is enabled in the project settings!).
 
 This makes them ideal for code that creates dozens of thousands of instances in servers and controls them from threads. Of course, it requires a bit more code, as this is used directly and not within the scene tree.
 

tutorials/performance/using_multimesh.rst

@@ -35,7 +35,7 @@ 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
-:ref:`VisualServer.multimesh_set_buffer() <class_VisualServer_method_multimesh_set_buffer>`
+:ref:`RenderingServer.multimesh_set_buffer() <class_RenderingServer_method_multimesh_set_buffer>`
 function). This way, the array can be created with multiple threads, then set in one call, providing
 high cache efficiency.
 

tutorials/performance/using_servers.rst

@@ -33,7 +33,7 @@ At the core, Godot uses the concept of Servers. They are very low-level APIs to
 rendering, physics, sound, etc. The scene system is built on top of them and uses them directly.
 The most common servers are:
 
-* :ref:`VisualServer <class_VisualServer>`: handles everything related to graphics.
+* :ref:`RenderingServer <class_RenderingServer>`: handles everything related to graphics.
 * :ref:`PhysicsServer <class_PhysicsServer>`: handles everything related to 3D physics.
 * :ref:`Physics2DServer <class_Physics2DServer>`: handles everything related to 2D physics.
 * :ref:`AudioServer <class_AudioServer>`: handles everything related to audio.
@@ -67,11 +67,11 @@ For nodes, there are many functions available:
   method will return the viewport RID in the server.
 * For 3D, the :ref:`World <class_World>` resource (obtainable in the :ref:`Viewport <class_Viewport>`
   and :ref:`Spatial <class_Spatial>` nodes)
-  contains functions to get the *VisualServer Scenario*, and the *PhysicsServer Space*. This
+  contains functions to get the *RenderingServer 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 :ref:`Viewport <class_Viewport>`
   and :ref:`CanvasItem <class_CanvasItem>` nodes)
-  contains functions to get the *VisualServer Canvas*, and the *Physics2DServer Space*. This
+  contains functions to get the *RenderingServer 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>`
@@ -94,23 +94,23 @@ This is an example of how to create a sprite from code and move it using the low
     extends Node2D
 
 
-    # VisualServer expects references to be kept around.
+    # RenderingServer expects references to be kept around.
     var texture
 
 
     func _ready():
         # Create a canvas item, child of this node.
-        var ci_rid = VisualServer.canvas_item_create()
+        var ci_rid = RenderingServer.canvas_item_create()
         # Make this node the parent.
-        VisualServer.canvas_item_set_parent(ci_rid, get_canvas_item())
+        RenderingServer.canvas_item_set_parent(ci_rid, get_canvas_item())
         # Draw a texture on it.
         # Remember, keep this reference.
         texture = load("res://my_texture.png")
         # Add it, centered.
-        VisualServer.canvas_item_add_texture_rect(ci_rid, Rect2(texture.get_size() / 2, texture.get_size()), texture)
+        RenderingServer.canvas_item_add_texture_rect(ci_rid, Rect2(texture.get_size() / 2, texture.get_size()), texture)
         # Add the item, rotated 45 degrees and translated.
         var xform = Transform2D().rotated(deg2rad(45)).translated(Vector2(20, 30))
-        VisualServer.canvas_item_set_transform(ci_rid, xform)
+        RenderingServer.canvas_item_set_transform(ci_rid, xform)
 
 The Canvas Item API in the server allows you to add draw primitives to it. Once added, they can't be modified.
 The Item needs to be cleared and the primitives re-added (this is not the case for setting the transform,
@@ -121,7 +121,7 @@ Primitives are cleared this way:
 .. tabs::
  .. code-tab:: gdscript GDScript
 
-    VisualServer.canvas_item_clear(ci_rid)
+    RenderingServer.canvas_item_clear(ci_rid)
 
 
 Instantiating a Mesh into 3D space
@@ -135,24 +135,24 @@ The 3D APIs are different from the 2D ones, so the instantiation API must be use
     extends Spatial
 
 
-    # VisualServer expects references to be kept around.
+    # RenderingServer expects references to be kept around.
     var mesh
 
 
     func _ready():
         # Create a visual instance (for 3D).
-        var instance = VisualServer.instance_create()
+        var instance = RenderingServer.instance_create()
         # Set the scenario from the world, this ensures it
         # appears with the same objects as the scene.
         var scenario = get_world().scenario
-        VisualServer.instance_set_scenario(instance, scenario)
+        RenderingServer.instance_set_scenario(instance, scenario)
         # Add a mesh to it.
         # Remember, keep the reference.
         mesh = load("res://mymesh.obj")
-        VisualServer.instance_set_base(instance, mesh)
+        RenderingServer.instance_set_base(instance, mesh)
         # Move the mesh around.
         var xform = Transform(Basis(), Vector3(20, 100, 0))
-        VisualServer.instance_set_transform(instance, xform)
+        RenderingServer.instance_set_transform(instance, xform)
 
 Creating a 2D RigidBody and moving a sprite with it
 ---------------------------------------------------
@@ -170,7 +170,7 @@ and moves a :ref:`CanvasItem <class_CanvasItem>` when the body moves.
 
     func _body_moved(state, index):
         # Created your own canvas item, use it here.
-        VisualServer.canvas_item_set_transform(canvas_item, state.transform)
+        RenderingServer.canvas_item_set_transform(canvas_item, state.transform)
 
 
     func _ready():
@@ -198,7 +198,7 @@ The 3D version should be very similar, as 2D and 3D physics servers are identica
 Getting data from the servers
 -----------------------------
 
-Try to **never** request any information from ``VisualServer``, ``PhysicsServer`` or ``Physics2DServer``
+Try to **never** request any information from ``RenderingServer``, ``PhysicsServer`` or ``Physics2DServer``
 by calling functions unless you know what you are doing. These servers will often run asynchronously
 for performance and calling any function that returns a value will stall them and force them to process
 anything pending until the function is actually called. This will severely decrease performance if you

tutorials/rendering/multiple_resolutions.rst

@@ -403,15 +403,9 @@ Reducing aliasing on downsampling
 
 If the game has a very high base resolution (e.g. 3840×2160), aliasing might
 appear when downsampling to something considerably lower like 1280×720.
-Aliasing can be made less visible by shrinking all images by a factor of 2
-upon loading. This can be done by calling the method below before
-the game data is loaded::
 
-    VisualServer.texture_set_shrink_all_x2_on_set_data(true)
-
-Alternatively, you can also enable mipmaps on all your 2D textures. However,
-enabling mipmaps will increase memory usage which may be problematic on low-end
-mobile devices.
+To resolve this, you can enable mipmaps on all your 2D textures. However, enabling mipmaps
+will increase memory usage which may be problematic on low-end mobile devices.
 
 Handling aspect ratios
 ----------------------

tutorials/rendering/viewports.rst

@@ -156,7 +156,7 @@ it using (for example):
 ::
 
    # Wait until the frame has finished before getting the texture.
-   yield(VisualServer, "frame_post_draw")
+   await RenderingServer.frame_post_draw
    # You can get the image after this.
 
 Viewport Container