A scene is not a GPU workload

The same scene can ask very different things of a desktop GPU, a phone, and a headset. Keeping the scene coherent across those devices does not mean asking all of them to execute the same rendering work. That distinction is at the centre of OmiLith, the real-time rendering engine I am building.

I want the authored world to keep its meaning: the lights, materials, environment, and relationships between effects. The renderer then needs room to decide how to produce that world within the device’s limits. A quality setting is useful only when it describes a workload that actually fits.

Start with a render plan

OmiLith resolves a render plan from the view, device capabilities, and the game’s quality policy before sending the selected path through a native backend. This makes the choice of work explicit, rather than leaving each effect to make unrelated decisions later.

It is a practical separation. A game owns its scene and what it wants to express. The rendering system owns the available techniques, their inputs, and the tradeoffs between them. The device provides the constraints. None of those pieces can answer the whole question in isolation.

The architecture is still developing, but this is the direction: one scene contract with room for several implementations. A simpler implementation should preserve the intent it can support, while being honest about the detail it leaves out.

Submission has a budget too

The work starts before a pixel is shaded. For each view, the engine extracts visible scene data, culls on the CPU, selects level of detail using projected error with hysteresis, and instances repeated geometry. Transparency has an explicit sorted phase.

There is a temptation to assume that a more elaborate submission path is automatically better. In practice, small scenes can stay on a direct path, while larger scenes can benefit from sharing more work. GPU culling is optional because it brings compute and indirect-draw overhead of its own. It earns its place when the submission work it saves outweighs that overhead.

This is why I prefer to think in terms of selected paths rather than a list of impressive features. The question is not simply whether the engine supports a technique. It is when that technique improves the frame.

Make the cheaper route deliberate

The same principle applies to effects. A full volumetric cloud path can use reduced-resolution marching, capped steps, early termination, and a separate cadence for cloud shadows. A less expensive device can use layered clouds and analytic fog instead.

These are different workloads. They should have clear inputs and a defined relationship to the authored environment, rather than being a set of disconnected switches. The lower-cost route needs to be designed and checked as a rendering path in its own right.

For a measured 60 Hz phone route in the development journal, the simpler ambient-occlusion and quality profile fit the budget better than the full profile. That observation applies to that device and route. It is a reason to measure the decision, not a rule that the same choice is right everywhere.

Keep the evidence next to the image

Cross-platform captures are useful for seeing whether the world still reads consistently. They are not a performance ranking. Different profiles, viewpoints, and devices can produce a useful visual comparison while doing substantially different work.

The performance question needs its own boundary: which device, which route, which profile, and which measurement conditions. A short capture also cannot establish thermal behaviour over a long session.

The most useful outcome is a renderer whose decisions can be explained. The image tells us what the selected path achieves. The measurement tells us what that particular path costs. Keeping both visible makes it easier to decide what to build next.