Simulation and graphics are often taught as separate disciplines: physics on one side, rendering on the other. In real-time engines, however, they are tightly connected stages of the same pipeline, with data moving from CPU to GPU in a predictable rhythm every frame.
Using the Particle Playground engine as a concrete example, this article examines the patterns that connect simulation, transformation, batching, and rendering into one coherent flow.
Every frame in a real time engine follows the same high level pattern:
Even simple demos follow this pattern; they simply skip some stages.
For the Particle Playground, the pipeline is:
This perspective is valuable because it shifts attention from isolated objects to the flow of data.
Simulation produces the data.
Graphics consumes that data.
The engine coordinates that movement clearly, efficiently, and at the right time.
Many modern engines use Entity Component Systems (ECS), and for large projects they can be an excellent fit. In a compact project or educational demo, however, a full ECS can add more structure than the design requires.
Particle Playground uses a lighter composition-based approach:
The design preserves the practical benefits of ECS:
It also avoids the overhead of:
The result is an architecture that stays small, explicit, and easy to reason about.
In an engine, execution order is a design decision.
For particles, the transform stage is intentionally simple: each particle needs only a position. The same pattern, however, scales cleanly to more complex objects.
A typical frame pipeline looks like this:
This ordered sequence becomes the backbone that keeps the engine predictable.
Batching is one of the central performance patterns in real-time graphics.
Every draw call, buffer update, and state change carries a cost.
Batching keeps that cost under control by letting the engine:
Particles are naturally suited to batching because they share:
That is why the Playground uses:
ppg_array<particle> particle_system;
rather than:
std::vector<some_entity*> entities;
Contiguous data enables fast iteration, straightforward batching, and predictable performance.
Templates are powerful, but they are most effective when used with restraint.
Use templates when they clarify types or compile-time behavior, such as:
Avoid using them to define broad architectural behavior, such as:
In short: templates should clarify
The full Particle Playground pipeline is easiest to understand as a set of cooperating layers:
Together, these layers form a practical engine architecture: small enough to study, clean enough to maintain, and structured enough to grow.
A single frame makes the architecture concrete:
float dt = btm::get_elapsed_time(); // btm-framework is the backbone
sim.step_simulation(dt);
matrix4 view = camera.view_matrix();
matrix4 projection = camera.projection_matrix();
renderer.init(positions, colors);
renderer.render(camera, positions);
Inside render(), the renderer performs four operations:
begin_render(draw_surface);
end_render(draw_surface);
while (application_active()) { ... }
Together, these steps capture the engine loop in miniature.
These patterns make engines easier to build, extend, and debug. More importantly, they help systems remain:
They also mark the difference between:
At this point, Particle Playground has become a modular, pipeline-driven engine: approachable enough to understand and structured enough to extend.
Simulation and graphics are not separate worlds. They are stages of a single pipeline, unified by:
This article closes the series by showing how the earlier ideas connect into one cohesive engine model.
The series now forms a complete learning path:
Together, these articles build an intermediate-level arc from language fundamentals to engine architecture.
Having explored the patterns for simulation and graphics, we will proceed with the exploration of simulation. This is the central topic in our 'Simulation Series'.