Architecture

HxEngine is organised as a stack of layers. The rule is simple and strict: lower layers never reference upper layers. This keeps the runtime decoupled from the editor and lets each system be tested in isolation.

The layer stack

Hx.Foundation → Hx.Core → Hx.Graphics.RHI → Hx.Graphics.D3D11
→ Hx.Platform → Hx.Rendering → Hx.Engine
→ Hx.Physics / Hx.Modeling / Hx.Animation / Hx.Audio / Hx.UI
→ Hx.Editor

Layer	Responsibility
Hx.Foundation	Math, containers, low-level utilities — no engine concepts.
Hx.Core	Object model, entities/components, assets, serialization.
Hx.Graphics.RHI	Render hardware interface — a backend-agnostic abstraction.
Hx.Graphics.D3D11	The Direct3D 11 implementation of the RHI (via Vortice).
Hx.Platform	Windowing, input, timing.
Hx.Rendering	Deferred PBR pipeline, post-processing, render graph.
Hx.Engine	Ties the runtime together — worlds, scenes, the game loop.
Hx.Physics / Modeling / Animation / Audio / UI	Feature systems built on the runtime.
Hx.Editor	The Avalonia editor — the only layer that knows about all the rest.

Key decisions

A few architectural choices shape the engine:

• No archetype ECS. An ECS-style entity/component model is used, but a full archetype ECS was evaluated and rejected (ADR-002).
• D3D11 first, RHI abstracted. WebGPU was considered and rejected (ADR-001); the RHI keeps the door open for a future Vulkan backend.
• Avalonia for the editor. Cross-platform UI with docking (ADR-003), with Dock.Avalonia vendored for stability (ADR-004).

Note

These are summaries. The full architecture decision records are part of the engine documentation provided with access.

Render hardware interface (RHI)

Rendering code is written against Hx.Graphics.RHI, not D3D11 directly. The D3D11 backend implements that interface. New backends (e.g. Vulkan) can be added without touching Hx.Rendering or above.

See Rendering for the pipeline details.