SIM GEOMETRY measurements · compatibility · cost

Guide 06 / field geometry

Why FOV calculators disagree

Two calculators can use correct trigonometry and return different numbers because they answer different questions. Audit the quantity before judging the arithmetic.

When two FOV calculators disagree, the tempting response is to compare their largest displayed numbers and decide that one formula must be wrong. Often the arithmetic is not the disagreement. One tool reports a horizontal physical span, another reports vertical projection FOV, a third reports only the center screen, and a fourth assumes a curved screen is flat. Until the quantity, geometry, and game convention match, the numbers are not candidates for direct comparison.

Axis: horizontal and vertical are different angles

For a centered flat rectangle, horizontal span uses visible width and vertical span uses visible height: 2 × atan(size ÷ (2 × distance)). On a 16:9 panel, width is larger than height, so the horizontal angle is larger. A result near 53° horizontal and another near 31° vertical can describe the same 597.7 × 336.2 mm screen at the same 600 mm distance.

Aspect-ratio conversion only works when the projection assumptions are compatible. A vertical setting can generate a horizontal render angle from aspect ratio, but that rendered angle is not automatically the physical span of a curved display or a multi-projection triple rig. Label every copied number horizontal or vertical before comparing it. If a calculator does not label its axis, treat the result as unresolved rather than inferring the axis from its magnitude.

Game conventions make the distinction operational. The conventions record maps iRacing single displays to horizontal span, with official sources establishing its geometry calculator and rendering workflow while explicit axis naming remains the record’s evidence limitation (official iRacing setup evidence). ACC single displays map to vertical span on the listed specialist evidence (ACC vertical-convention source). Copying the same numeric field between those games would ignore the documented convention difference.

Span: which edges define the number?

A single screen has an intuitive left edge and right edge. Triples introduce several defensible spans. centerSpan covers only the middle active image. visibleEnvelope runs from the outer visible edge on the left side panel to the outer visible edge on the right. activeImageCoverage subtracts the two bezel occlusions from that envelope. A renderer may also describe a bezel-corrected virtual pixel span.

These quantities answer different questions, so multiplying the center span by three is not a neutral shortcut. Side panels rotate around hinges; their endpoints occupy rays determined by yaw and distance. Bezels interrupt the active image without necessarily moving the outer envelope by the same amount. Ask a calculator whether its triple result is per panel, center only, total visible envelope, or a rendered correction.

Game mode decides which span matters. iRacing’s official instructions distinguish three-projection rendering and gather width, bezel, distance, and angle (official iRacing triple workflow); its native triple mapping uses the full visibleEnvelope. ACC’s current record instead maps triples to physical geometry, supported by official v1.8 evidence for a named Triple Screen rendering mode (official ACC v1.8 mode evidence). Do not force either case into an invented total-degrees field.

Curvature: chord, arc, and edge depth

A flat calculator places both edges in the plane of the screen center. This calculator treats curved-screen visible width as a chord of a concave circle. Radius and chord determine sagitta; the edges then sit closer to the eye than the center, which widens the physical angle. Another tool may treat width as arc length, assume eye distance equals curve radius, approximate the curve as flat, or report the projection angle instead of the physical edge span.

None of those choices should be hidden behind a generic “curved” checkbox. Record whether width means straight chord or surface-following arc, whether distance ends at the center or edge, whether the panel is concave, and what the returned angle represents. At 49-inch-class 32:9 dimensions, 1800R, and 800 mm center distance, this calculator reports about 81.3° physical horizontal span versus about 73.6° for the same chord treated as flat. The gap comes from a declared geometric assumption.

Inputs: marketed dimensions versus visible dimensions

Diagonal and aspect ratio infer an ideal visible rectangle. Direct active-image width and height describe the actual endpoints used by the ray calculation. A calculator may include the bezel in screen width, use a manufacturer’s nominal diagonal, or round inch-to-millimetre conversion before applying trigonometry. Eye distance can likewise be measured to the panel center, cabinet, stand, or an edge of a curve. Small input differences become angular differences.

For a fair audit, give both calculators the same visible width, visible height, and eye-to-visible-center distance in the same unit. On triples, align the definition of bezel—per side or total seam—and the definition of angle—yaw from straight or interior hinge angle. On curves, align radius and chord meaning. If a field cannot be made equivalent, note the mismatch and stop claiming a formula comparison.

Rounding and presentation

Rounding can occur in the measurements, internal calculation, displayed result, or game control. A tool that shows whole degrees may have computed more precisely; a game slider may accept a step the documentation does not state. Compare unrounded outputs when available, then round once at the final interface boundary. Do not add false precision by converting a whole-degree answer into a decimal.

Sensitivity can also look like disagreement. This calculator evaluates the same rig at eye distance minus and plus 10 mm. If another result lies within that band, the first question is whether the physical eye point is repeatable—not whether one tool should be tuned to match the other. The band quantifies one input dependency; it does not certify either calculator.

A seven-question audit

  1. What is the output axis? Horizontal, vertical, or undisclosed?
  2. What is the span basis? One panel, center panel, full envelope, active coverage, or a corrected render span?
  3. What projection is assumed? Flat rectilinear, curved physical surface, Pannini-adjusted, or native multi-projection?
  4. What do width and distance mean? Visible chord and center surface, or some cabinet and arc alternative?
  5. How are triples defined? Per-side bezel versus total seam; yaw from straight versus interior angle?
  6. Where does rounding happen? Input, calculation, display, or the game field?
  7. What evidence maps the physical result to the game? Current official documentation, dated specialist evidence, or an unlabeled assumption?

Check this calculator too

Use the published formulas and assumptions to align input definitions and output names before comparing results. If your rig does not match an assumption, record the mismatch instead of treating the two numbers as equivalent.

The link below freezes a triple state with measured dimensions, resolution, bezel, manual 54.01° yaw, and the iRacing selection. Give those same normalized inputs to another calculator. Compare center span with center span and envelope with envelope. If the result still differs, the remaining discrepancy is narrow enough to investigate at the formula or projection layer.

Open one reproducible state for a calculator audit

A calculator disagreement becomes useful when it reveals an unnamed convention. Preserve the inputs, output label, formula assumptions, game evidence, and rounding boundary. Once those are visible, “which number is right?” becomes the more answerable question: “which number describes the quantity this renderer and this physical rig actually need?”

External sources