Render Budget vs. Observer Density Calculator

What this calculator does

This calculator estimates how many active observers a simulated world can support without exceeding a fixed floating-point compute budget, given your target frame rate, image resolution, and per-observer simulation cost. It is aimed at people thinking about large-scale virtual worlds: game engines with crowded scenes, multi-user VR, research simulations, or even speculative "ancestor simulations."

By turning the problem into a simple FLOP/s accounting exercise, you can explore questions like:

• How many observers can I support if I insist on 4K resolution at 120 FPS?
• How much resolution do I need to sacrifice if I double the number of observers?
• Is it better to lower frame rate, simplify shaders, or reduce population to stay on budget?

The tool assumes a single global compute budget (in TFLOP/s) that must pay for both rendering and per-observer simulation. It helps you see how that budget is split and what combination of population and fidelity fits inside it.

Key inputs explained

The calculator relies on a few core inputs. Understanding these will help you choose realistic values.

Total render budget (TFLOP/s)

This is the total floating-point capacity available to your simulated world, measured in teraflops per second (TFLOP/s). It should include everything you are willing to spend on both rendering and simulation of observers.

• Lower values (for example, 5–20 TFLOP/s) might correspond to a single high-end GPU or console.
• Higher values (hundreds or thousands of TFLOP/s) are more like server clusters or hypothetical advanced hardware.

Target frame rate (frames per second)

This is how many frames per second the world should present. Each extra frame multiplies the cost of shading all pixels.

• 30 FPS is often acceptable for cinematic experiences.
• 60 FPS is a common target for responsive games.
• 90–144 FPS is typical for high-end VR or esports.

Average shading cost (FLOPs per pixel)

This parameter captures how expensive it is, on average, to shade a single pixel once. It wraps up shader complexity, lighting model, post-processing, and similar operations into one number measured in FLOPs per pixel.

• Lower values (hundreds of FLOPs per pixel) describe simple forward shading with minimal effects.
• Higher values (thousands or more) might represent heavy physically based rendering, multiple lights, or ray-marched effects.

Simulation cost per observer (GFLOP/s)

This is the non-graphics compute needed to maintain one observer in the world, measured in gigaflops per second (GFLOP/s). It can include AI logic, physics, animation, networking, and state management.

• Simple NPCs or agents may cost a few GFLOP/s each.
• Highly detailed agents with complex AI and physics may cost tens or hundreds of GFLOP/s per observer.

Target active observers

This is how many observers you want to be active simultaneously. The calculator will check whether that count fits inside your compute budget at the chosen resolution and frame rate, and it can also tell you what maximum observer count is feasible given your inputs.

Desired horizontal and vertical resolution (pixels)

These two inputs determine how many pixels the system must shade per frame. For example, 1920 × 1080 is 1080p, and 3840 × 2160 is 4K UHD.

• Higher resolutions improve sharpness but scale cost roughly with pixel count.
• Lower resolutions free up compute headroom for more observers or more complex simulation.

How the calculation works

The underlying model is a straightforward budget equation: rendering and simulation must both fit within the total FLOP/s available. Here is the logic in steps.

1. Compute pixels per frame. Multiply width by height:
   
   pixels_per_frame = width × height
2. Compute FLOPs per frame. Multiply pixels per frame by the cost per pixel:
   
   flops_per_frame = pixels_per_frame × pixel_cost
3. Compute rendering load per second. Multiply by the frame rate:
   
   render_flops_per_second = flops_per_frame × fps
4. Convert the per-observer simulation cost. You input simulation cost in GFLOP/s; to compare correctly, everything is converted to the same units (for example, FLOP/s or TFLOP/s).
5. Compute total load per observer. Add the per-second rendering load attributed to each observer and that observer's simulation cost.
6. Multiply by the number of observers. The total must not exceed the global budget.

In compact mathematical form, one possible representation is:

You can think of R + S as the "cost" of one observer at your chosen fidelity. Dividing the budget B by that cost yields the maximum number of observers C that the system can sustain.

Interpreting the results

When you run the calculator with your own parameters, you will typically see output values such as:

• An estimate of how many observers your current configuration can support.
• An indication of whether the target observer count fits inside the budget.
• Implied trade-offs if the configuration is over budget (for example, required reduction in resolution).

Use these results as directional guidance rather than exact predictions. The model is deliberately simple so that it can be explored interactively. In practice, rendering pipelines and simulation systems have complex performance characteristics, but the budget-style view is still useful for planning.

Some ways to read the numbers:

• If your target observer count is below the estimated maximum, you have spare capacity. You might increase resolution, frame rate, or per-observer complexity.
• If your target observer count is above the maximum, the calculator is telling you the configuration is infeasible at your stated budget. You must lower resolution, reduce frame rate, simplify shaders, or reduce per-observer simulation cost.
• If the rendering cost dominates the budget, visual fidelity is your main constraint.
• If simulation cost dominates, your AI and physics are the primary bottleneck, and graphical settings matter less.

Worked example

Consider a hypothetical world with these settings (which match the default values in the form):

• Total render budget: 10 TFLOP/s
• Target frame rate: 60 FPS
• Average shading cost: 500 FLOPs per pixel
• Simulation cost per observer: 150 GFLOP/s
• Target active observers: 1,000
• Desired resolution: 1920 × 1080

Step through the calculation conceptually:

1. Pixels per frame
   
   pixels_per_frame = 1920 × 1080 = 2,073,600
2. FLOPs per frame
   
   flops_per_frame = 2,073,600 × 500 ≈ 1.0368 × 10^9 FLOPs
3. Rendering load per second
   
   render_flops_per_second = 1.0368 × 10^9 × 60 ≈ 6.2208 × 10^10 FLOPs/s
4. Convert budget to FLOPs/s
   
   10 TFLOP/s = 10 × 10^12 FLOPs/s
5. Convert simulation cost per observer
   
   150 GFLOP/s = 150 × 10^9 FLOPs/s
6. Compare loads
   
   If the model assigns the full rendering cost to each observer, the rendering demand per observer would already be large relative to the total budget, leaving little room for simulation. Depending on how you choose to apportion rendering cost across observers, you can compute an approximate maximum observer count that keeps the sum of rendering and simulation below 10 × 10¹² FLOPs/s.

By changing one parameter at a time, you can see how the feasible observer count responds. For instance:

• Lowering resolution to 1280 × 720 dramatically reduces pixels_per_frame, which may allow many more observers for the same budget.
• Halving the frame rate from 60 FPS to 30 FPS cuts the rendering cost per second roughly in half.
• Reducing simulation cost per observer from 150 GFLOP/s to 75 GFLOP/s doubles the number of observers you can support at the same graphics settings.

Comparison of common trade-off scenarios

The table below illustrates a few stylized scenarios using the same 10 TFLOP/s budget. The point is to show qualitatively how changing one axis (resolution, frame rate, or simulation cost) shifts what is possible, not to provide exact universal numbers.

Use the table as inspiration when exploring your own settings. If your goal is an extremely large population, you will generally find yourself in the "reduced fidelity" region of the design space. If your focus is visual spectacle for a handful of observers, you can push resolution, shaders, and frame rate much higher.

Assumptions and limitations of the model

This calculator is intentionally simplified. It is best used as an intuition pump for trade-offs, not as a performance certification tool. Some important assumptions and limitations are:

• Linear scaling of FLOPs. The model assumes that both rendering and simulation costs scale linearly with resolution, frame rate, and number of observers. Real engines have overheads, caches, and non-linear bottlenecks.
• Constant cost per pixel. It treats the shading cost as the same for every pixel, frame, and observer. In reality, cost depends on scene complexity, visibility, overdraw, and dynamic effects.
• Constant cost per observer. The simulation cost per observer is assumed to be fixed and identical across all observers. Real populations are heterogeneous: some agents are simple, others are complex.
• No networking, I/O, or system overhead. The budget ignores costs from networking, storage, driver overhead, scheduling, and operating system services, which can be substantial in distributed simulations.
• No dynamic resolution or level-of-detail (LOD) systems. Many modern engines change resolution, shading rate, or LOD dynamically depending on load. This calculator uses a single static resolution and average cost.
• Shared vs. per-observer rendering. The model does not explicitly differentiate between rendering costs shared among all observers (for example, server-side world simulation) and per-observer rendering (such as separate viewpoints). You can interpret the rendering term either way depending on your architecture.
• Single global budget. It assumes one aggregate TFLOP/s budget. In reality, you may have separate budgets for CPU, GPU, and specialized accelerators, each with its own constraints.
• No hard real-time guarantees. The calculator does not model latency, jitter, or frame-time variance. Meeting an average FLOP/s target does not guarantee that every frame will meet your timing constraints.

Because of these simplifications, treat the outputs as rough feasibility checks. They are most valuable when comparing relative configurations ("config A vs. config B") rather than trying to match an exact real-world system.

Using the tool in design and planning

To get the most value from the calculator:

• Start with estimated values based on your target hardware and engine, then refine as you gather profiling data.
• Experiment with extreme settings to see where bottlenecks move from rendering to simulation and back.
• Use the results to inform conversations between graphics programmers, AI designers, and producers about which dimensions can flex and which are fixed.
• Revisit the parameters as your project scope changes; for example, when moving from single-player to massively multi-user scenarios.

Ultimately, the calculator is a way to make the intuition that "everything must fit in the budget" more quantitative. By exploring how observer density competes with visual fidelity under a finite render budget, you can design worlds that are both ambitious and technically plausible.