Inside QubicEngine

A world is a collection of decisions#

An engine is the machinery between a creator’s intention and a player’s experience. If a character walks into a room, the engine changes its position, blends its animation, checks collisions, loads nearby assets, calculates visibility, builds GPU commands, and updates the sounds around the listener. A renderer is one part of that machinery. QubicEngine organizes this work around explicit ownership. The simulation owns the world’s state. The renderer owns its GPU resources. The asset system bridges files and runtime objects. Each boundary has a defined data format and a defined point at which work becomes visible to another system.

The systems and their contracts#

The main thread runs input and coordinates updates. A job system parallelizes independent simulation and import tasks. A render thread consumes an immutable RenderWorld snapshot instead of reaching into components while another thread changes them.

Follow an object#

A model file enters AssetStore as a request. Decoding produces mesh vertices, indices, material slots, and animation tracks. Upload work fills GPU resources, and completion publishes a ready asset version. A MeshRenderer component keeps an asset handle and material overrides, rather than storing a raw graphics API pointer. During extraction, the renderer copies the object’s world matrix, bounds, mesh handle, material handle, and optional skin palette into RenderWorld. Visibility selects useful instances. RenderGraph orders passes and resource transitions. GraphicsDevice turns those decisions into DirectX 12 commands, or Vulkan commands when that backend is selected.

Rendering choices#

QubicEngine’s reference renderer uses deferred lighting for opaque surfaces, tiled light lists, forward shading for transparency, a linear HDR intermediate, temporal reconstruction, and tone mapping into a display image. Shadows and global illumination supply additional lighting inputs. The advanced chapters explain where each approximation spends memory, compute time, or quality. A Vulkan backend implements the same resource and command contracts. The primary learning path uses DX12 because it makes the ownership and scheduling choices concrete on Windows. Shared C++ systems do not imply identical API objects or identical barrier rules.

Choose a system to inspect#