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.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions