RenderingServer

    Server for anything visible.

    RenderingServer.swift:34
    class RenderingServer

    The rendering server is the API backend for everything visible. The whole scene system mounts on it to display. The rendering server is completely opaque: the internals are entirely implementation-specific and cannot be accessed.

    The rendering server can be used to bypass the scene/Node system entirely. This can improve performance in cases where the scene system is the bottleneck, but won’t improve performance otherwise (for instance, if the GPU is already fully utilized).

    Resources are created using the *_create functions. These functions return RIDs which are not references to the objects themselves, but opaque pointers towards these objects.

    All objects are drawn to a viewport. You can use the Viewport attached to the SceneTree or you can create one yourself with viewportCreate. When using a custom scenario or canvas, the scenario or canvas needs to be attached to the viewport using viewportSetScenario(viewport:scenario:) or viewportAttachCanvas(viewport:canvas:).

    Scenarios: In 3D, all visual objects must be associated with a scenario. The scenario is a visual representation of the world. If accessing the rendering server from a running game, the scenario can be accessed from the scene tree from any Node3D node with getWorld3d. Otherwise, a scenario can be created with scenarioCreate.

    Similarly, in 2D, a canvas is needed to draw all canvas items.

    3D: In 3D, all visible objects are comprised of a resource and an instance. A resource can be a mesh, a particle system, a light, or any other 3D object. In order to be visible resources must be attached to an instance using instanceSetBase(instance:base:). The instance must also be attached to the scenario using instanceSetScenario(instance:scenario:) in order to be visible. RenderingServer methods that don’t have a prefix are usually 3D-specific (but not always).

    2D: In 2D, all visible objects are some form of canvas item. In order to be visible, a canvas item needs to be the child of a canvas attached to a viewport, or it needs to be the child of another canvas item that is eventually attached to the canvas. 2D-specific RenderingServer methods generally start with canvas_*.

    Headless mode: Starting the engine with the --headless command line argument disables all rendering and window management functions. Most functions from RenderingServer will return dummy values in this case.

    This object emits the following signals:

    Superclasses

    Citizens in SwiftGodot

    Conformances

    • protocol CustomStringConvertible

      A type with a customized textual representation.

    • protocol Equatable

      A type that can be compared for value equality.

    • protocol Hashable

      A type that can be hashed into a Hasher to produce an integer hash value.

    • protocol Identifiable<ID>

      A class of types whose instances hold the value of an entity with stable identity.

    • protocol VariantRepresentable

      Types that conform to VariantRepresentable can be stored directly in Variant with no conversion. These include all of the Variant types from Godot (for example GString, Rect, Plane), Godot objects (those that subclass SwiftGodot.Object) as well as the built-in Swift types UInt8, Int64 and Double.

    • protocol VariantStorable

      Types that conform to VariantStorable can be stored in a Variant and can be extracted back out of a Variant.

    Types

    Type members

    Instance members