Skip to content

Add a RenderLayer system for global render ordering #3967

Description

@spydon

Motivation

priority only orders siblings, so the draw order of a component is tied to where it sits in the tree. Games regularly need cross-hierarchy ordering (a health bar above all enemies, a projectile under all UI) and the current workaround is restructuring the tree so competitors share a parent.

Proposal

A RenderLayer system, similar in spirit to Godot's CanvasLayer and Unity's sorting layers:

  • A World (per camera pass) owns an ordered set of layers; each layer has a z-index.
  • Components can declare a target layer; their rendering is routed to that layer instead of their tree position, while updating, lifecycle, and hit-testing stay hierarchical.
  • Plain PositionComponents are replayed onto their layer using their cached absolute transform. Subtrees with hierarchical render state (clips, decorators, snapshots, custom renderTree) stay atomic: they render as a unit at their subtree's layer.
  • The flattened-traversal infrastructure from Make the Flame Component System core more efficient #3957 (structure versioning, lazily rebuilt root-owned lists) carries over directly for maintaining per-layer render lists.

This also follows the design note in #3957 about separating render order from update order, and would give y-sort a render-time home (a layer sorted by position.y) with zero structural reordering.

Out of scope

Arbitrary interleaving of components across clip/decorator boundaries; those subtrees remain atomic within a layer.

Related: #3957, and the "Support a global z-index/priority" item in #1938.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions