Stop Using Nodes for Everything in Godot

Key problem & performance impact

• In the creator’s Godot game Alchemortis (dark fantasy roguelite auto-battler), rendering an unlock screen previously took about 115 ms for the screen—roughly ~7 dropped frames.
• The cause was that each card was a Godot scene instantiated with many child nodes and materials/visual effects.
• Instantiating ~100 card scenes in a single frame caused a massive process-time spike.

Attempts to fix it (per the subtitles):

• Object pooling
• Spreading instantiation across multiple frames
• Other approaches

Ultimately, these felt like fragile workarounds and didn’t meet the performance needs.

Core conclusion

• The creator’s real fix was to reduce node overhead.
• The original approach—“instantiate card scenes and add lots of nodes to the tree”—wasn’t feasible for the required performance.
• They tested using Godot’s RenderingServer directly, rather than relying on node-based rendering.

Why RenderingServer helps (technical concept)

• Nodes like Sprite2D are essentially configuration wrappers: they pass rendering data to the RenderingServer.
• By using the RenderingServer directly, you can bypass overhead from:
  • Instantiating scenes
  • Adding many nodes into the scene tree
  • Letting node logic mediate rendering work

RenderingServer setup pattern (guide-style breakdown)

1) Create a canvas item backed by RenderingServer

• Register a new canvas item that supports transform, texture, material, etc.
• The call returns an RID (Resource ID).

2) Manage lifecycle explicitly

• You must manage RIDs manually.
• Free RIDs explicitly when they’re no longer needed.

3) Configure rendering

• Assign textures (e.g., canvas_item_add_texture_rect)
• Assign materials
• Set transforms with canvas_item_set_transform (position/rotation/scale)

4) Use hierarchical transforms

• Canvas items created via RenderingServer can be parented as children of other canvas items.
• This lets them inherit transforms—similar to Node2D parenting behavior.

Refactor result (product feature / benchmark)

• The “card class” was redesigned:
  • It still inherits Control to keep mouse input support and allow potential reparenting.
  • But it creates no other nodes during card instantiation.
• Instead, the card’s setup method constructs an “almost pure RenderingServer” tree:
  • Canvas items for card background
  • Canvas item for art
  • Canvas items using materials for special visual effects/status visuals
  • Canvas item transforms used to support visual animations (scale/position)

Performance improvement

• Rendering ~100 cards in ~8 ms (debug build)
• Improved from 115 ms previously
• Described as a massively noticeable difference, comfortably within a single frame.

Main speakers/sources

• Primary speaker: The video creator (author/developer of Alchemortis, referenced throughout)
• Source topic: Godot engine RenderingServer (technical content about its APIs and RID/canvas-item workflow)