Skip to content

EntropyPortal Architecture

EntropyPortal is the client-side viewer and renderer for the Entropy ecosystem. It is designed as a modular, service-based application that consumes scene data from the network and renders it with high fidelity.

Unlike traditional game engines where the client simulates the world, EntropyPortal acts primarily as a terminal: it receives state updates from the server (EntropyCore/EntropyCanvas) and visualizes them. This separation of concerns allows the simulation to scale independently of the client’s rendering capabilities.

The application is structured around three main pillars:

  1. The Session: Manages network connectivity, authentication, and state synchronization.
  2. The Scene: Maintains a local ECS (Empowered by Flecs) that mirrors the server state.
  3. The Renderer: A high-performance, multithreaded rendering engine that visualizes the scene.
graph TD
    Network[Network Session] -->|Snapshots/Deltas| Scene[Scene Service]
    Scene -->|ECS Queries| Render[Render Service]
    Scene -->|Spatial Index| Visibility[Visibility Service]
    Render -->|Commands| GPU[GPU Device]
    Input[Input Service] -->|Events| Session

EntropyPortal uses the EntropyService pattern. Each major subsystem (Rendering, Scene, Input, Networking) is an independent service with a well-defined lifecycle (load, start, stop, unload). Services can inject dependencies into each other, forming a loosely coupled graph.

Materials are defined by data received from the network, not by hardcoded shaders. The AssetSystem resolves material definitions to local shader variants, allowing for dynamic content without client updates.

The renderer is designed for maximizing parallelism. It uses:

  • Work Graphs: To express dependencies between rendering tasks.
  • Work Contracts: To distribute work across thread pools.
  • N-Buffering: To allow the CPU to run ahead of the GPU without stalling.