Physics Engine Tuning (nFozzy & Beyond)

The definitive reference for VPW physics implementation. This guide consolidates every physics-related technique, constant, and code pattern developed across the VPW project from 2020 through 2025.

nFozzy Rubber Separation

Rubber separation is the foundation of nFozzy physics. Each rubber assembly on the real table is split into two collision zones with different physics materials, replacing the stock VPX rubber behavior with more realistic ball interaction.

The Three Components

Every rubber assembly produces three types of VPX objects:

Posts (dPosts collection) -- Invisible collidable cylinders placed where rubber wraps around posts. Assigned the z_col_rubberposts physics material. Added to the dPosts collection, which applies dampening on contact.

Sleeves (dSleeves collection) -- Sleeve-covered posts use the dSleeves collection instead of dPosts. The dSleeves collection has more damping than dPosts, making sleeves feel less bouncy, which is correct for rubber-sleeve-covered posts (learned from Ripley's Believe It or Not). Standard rubber sleeve physics objects should be approximately 20x20x20 VP units, derived from toolkit blueprint measurements of actual machine sleeves (learned from Star Trek TNG). Oversized sleeve primitives make the table harder than intended because the collision area is larger than the real rubber.

Bands (not in a dampening collection) -- Invisible collidable rectangles placed where rubber stretches between posts. Assigned the z_col_rubberbands physics material. These are NOT placed in the dPosts or dSleeves collection.

The original visible rubber stays visible but is set to non-collidable. Import the .vpp physics materials file if the material dropdowns are empty (learned from nFozzy Physics Guide).

Finding Collidable Rubbers

Tables often have both decorative high-poly rubber meshes (pretty but non-collidable) and functional low-poly collidable rubbers on different layers. Only the low-poly collidable rubbers should go into dPosts/dSleeves collections. To find them: toggle layers on/off, or use Edit > Select Object, sort by name, look for "rubber*" entries, and check which are collidable in the options panel. The pre-existing Rubbers collection (used for hit sounds) should remain as-is -- dPosts and dSleeves are additional collections (learned from nFozzy Physics Guide).

Rubber Band Rigging (5-Object Structure)

A single rubber band assembly requires 5 separate objects: 2 post primitives (the physical posts at each end), 2 rubber band walls (left and right sides of the rubber), and 1 middle section wall (the rubber between the posts). The walls handle physics collision while the primitives provide the visual posts. Short rubber material should be set between post elasticity and standard rubber band elasticity -- a custom material with intermediate values (learned from Fish Tales).

nFozzy Implementation Checklist

Standard nFozzy implementation order, compiled from the nFozzy Physics Guide and refined across dozens of table builds:

1. Make flipper meshes
2. Make RDampen timer (note: the rdampen_timer sub referenced in early tutorials is no longer needed in current implementations -- learned from VPW Example Table)
3. Paste Key down/up sub code
4. Add LF Fire/RF Fire to flipper code
5. Paste all nFozzy code as one big chunk
6. Double check for duplicate flipper Collide subs (duplicates are silently overridden -- learned from Austin Powers)
7. Sort out/make the rubbers (dPosts/dSleeves)
8. Import 90s flipper physics .vpp in table options panel
9. Test table

Critical warnings: - VPX "Global Physics Sets" must NEVER be used with nFozzy physics. Physics sets silently override nFozzy's tuned values, and the editor does NOT grey out overridden values, making the conflict invisible (learned from VPW Example Table). - Ball mass must always be 1. Even for widebody tables like Judge Dredd, "Ball mass of 1.3 will throw all of the flipper stuff off" (learned from Judge Dredd). - Imported physics materials can have their values silently zeroed out during certain VPX operations. Detection method: use the dotted ball (F11) and watch for abnormal inlane spin. If the ball reverses direction touching the flipper, re-import all physics materials (learned from Jokerz).

Flipper Tuning by Era

Polarity and Velocity Curves

The nFozzy polarity and velocity AddPt curves are NOT universal -- they vary by era (70s, 80s, 90s, etc.) to match the flipper coil power of that period. The VPW Example Table contains all era variants. When implementing nFozzy on a table, select the curve set matching the table's era. Different flipper travel amounts also exist across 90s games (learned from nFozzy Physics Guide).

When flipper shot angles feel wrong (too much toward backhand), try swapping the polarity curve to match a different era table. For Medieval Madness with misaligned layout: "Just change the polarity curve to what's in AFM" (learned from Physics Debate).

Flipper Strength Values

Flipper strength varies by table and coil type. Representative values from VPW builds:

Table	Era	Strength	Notes
Standard 90s Williams	WPC	~2800-3000	Baseline for most tables
Indiana Jones	WPC (11629 coil)	3250-3500	~15-20% above typical (learned from Indiana Jones)
Upper flippers (general)	Various	2400-2500	Lower than main flippers (learned from Iron Maiden)
TNA (Spooky)	Modern/WPC mechs	2500-3250	Uses WPC flipper mechanisms (learned from TNA)

Gottlieb System 3 tables require checking which flipper coil is installed -- Gottlieb issued a service bulletin upgrading the flipper coil from A-25959 (3.85 ohm) to A-29876 (2.36 ohm) for stronger flipper action. The lower-resistance coil produces noticeably more power (learned from Stargate).

Key Flipper Constants

EOSTorque -- Controls the flipper's held-position resistance. Increasing from 0.275 to 0.375 improves the "ball hop" when tapping a held flipper, used for tap passes (learned from Fish Tales).

EOSReturn -- Controls how quickly the flipper releases (returns to rest). Higher values (0.4 vs 0.35) make backhands stronger but also make flick passes harder -- both desirable for realistic gameplay. EOSReturn and EOSTorque interact -- combined adjustment (EOSReturn 0.4 + EOSTorque 0.375) produced more realistic flipper trick behavior than adjusting either alone (learned from Fish Tales).

Flipper return strength -- Value of 0.04-0.05 (vs default 0.11) feels more like real Stern machines per iaakki's testing on TWD. Flipper mass is generally too high in nFozzy, causing backhand shots with flipper held up to be unrealistically powerful. Lowering mass would require reworking flipper tricks, trajectory correction, and strength values (learned from Physics Debate).

SOSRampup -- Critically affects tap passes. With SOSRampup=2.5, tap passes don't work but flipper shots are more reliable. With SOSRampup=8.5, tap passes work but flippers feel slow. Recommended: 2.5, because VPX timer behavior doesn't adjust the rampup back correctly at higher values (learned from Austin Powers).

Flipper Overswing

A VPForums post claimed nFozzy flipper code had a bug because it extends 3 degrees beyond end angle. This is working as designed -- real flippers have play and the force of flipping pushes beyond the set end angle momentarily. The Dir variable changes +/- direction per flipper (learned from Physics Debate).

Flipper Trigger Sizing

Flipper triggers should be 27 VP units from the flippers (increased from 23 in 2024). The previous 23-unit margin was less than a ball radius (25 units), meaning the ball never entered the trigger from a cradled position -- velocity correction from cradle was silently broken. Additionally, add 3 degrees to the flipper end angle when sizing the trigger (then revert the flipper angle), because the built-in momentum overswing extends the flipper briefly past its end angle. To size: temporarily set end angle 3 degrees beyond actual (e.g., 67 instead of 70), create trigger, then restore flipper end angle (learned from VPW Example Table).

Trigger hit heights must be set to 150, and RF.PolarityCorrect Activeball: LF.PolarityCorrect Activeball must be added at the start of the drain_hit sub. Without these, balls draining during multiball cause the flipper trigger unhit event to not fire, producing recurring division-by-zero errors in the COR tracking code (first identified on Taxi, confirmed on T2).

Note on the 2024 standard: The 27-unit standard supersedes the earlier 23-unit standard documented in some channels. Older tables may still use 23 units (learned from VPW Example Table, Cirqus Voltaire).

Upper Flipper Simplification

For vertical upper flippers (typical right upper flipper location), full nFozzy trajectory correction is unnecessary. The shot is typically a quick reflex shot with no tricks needed. Just applying the nFozzy flipper properties in the object properties is sufficient. The nFozzy flipper correction script adjusts the ball's X-axis velocity relative to the table, not relative to the flipper surface -- for lower flippers oriented roughly horizontally, this approximation works well. For upper flippers at different angles, the correction pushes the ball in the wrong direction. Disable flipper correction on the upper flipper by removing the correction call from the upper flipper's solenoid callback (learned from nFozzy Physics Guide, Star Trek TNG).

Upper flippers should still have flipper tricks but NOT trajectory correction -- only main flippers get trajectory correction (learned from Iron Maiden).

Flipper Angle Calibration

Overlay the PAPA tutorial video with the VPX table to compare flipper angles. On Medieval Madness, initial angles were too extreme (too flat) -- correction required raising both up and down positions approximately 4-5 degrees (learned from Medieval Madness).

Flipper alignment rules: Start angle -- flippers should hang just a bit lower than the centerline of the nearest insert. End angle -- flipper tip goes just above the whip (lane guide). Flipper length -- outer rim of the insert edge rings. "This is not rocket science, but I've now seen like 10 tables where these are way off" (learned from Judge Dredd).

For Stern tables specifically, flipper end angle being 5 degrees too high compared to the real machine was found to be a common calibration mistake. In the VPX editor, uncheck "Physics Object" from Layers, then View > Playfield Image to overlay the flipper against the playfield art for visual alignment (learned from Iron Maiden).

nFozzy Flipper Angle Sign Convention

The Dir variable in nFozzy code changes +/- direction per flipper. For the right flipper, angles must use the negative convention. The overswing extension is 3 degrees in the appropriate direction based on Dir.

FlipperCradleCollision

During multiball, balls colliding on a held flipper produce unrealistically high velocities because ball-to-ball friction isn't modeled. The FlipperCradleCollision sub applies a COR dampening factor when one ball hits another while either is on a flipper held at end angle.

The final working code checks if either ball is on a flipper held at end angle using FlipperTrigger(ball.x, ball.y, Flipper), then applies DesiredBallCOR = 0.4 to all velocity components of both balls. Must be called from OnBallBallCollision. Reference implementation is in the Godzilla table and Example Table (learned from Physics Debate).

Inlane Live Catch

Real pinball allows a mini-live-catch at the flipper base when timing a flip to meet a ball rolling down the inlane. VPX originally excluded the flipper base from live catch code via LiveDistanceMin.

Key constants: - LiveDistanceMin = 5 (lowered from original value) - LiveDistanceMax = 114 - BaseDampen = 0.55

Logic: if LiveDist < 30 and ball moving toward tip (ball.velx * Dir > 0), apply BaseDampen to all velocity/angmom components. If LiveDist > 30, use standard live catch logic with LiveCatchBounce. Different velocities of incoming balls provide natural variation without needing randomness. Verified on real Simpsons and Transporter machines (learned from Physics Debate).

Slingshot Correction

VPX slingshot walls apply force perpendicular to the wall surface, but real slingshots deflect at an angle. Correction code adds rotational force. Based on video research, 4-7 degrees of correction is correct -- the initial 10-degree value was too high. The correction calls must be placed in _Slingshot event subs (not solenoid callbacks, which have a built-in cooldown where rapid re-fires are suppressed). Also requires dsin and dcos helper functions in the script (learned from VPW Example Table, Tommy).

"Nibble" shape research: The existing sling correction curve applies a large smooth correction across the sling face. Real slings (per Abe Flips analysis video) show more randomness/variation specifically near the sling arm center. apophis79 attempted an orange-line revision for Medieval Madness with larger variation near the arm area. The correction table needs scrubbing against Abe Flips' full physics analysis when released (learned from Physics Debate).

Dead zone and velocity-dependent activation: Real slings don't fire on hard hits near the top post. There's a dead area close to the sling post where rubber shouldn't make the switch. Sling behavior depends on solenoid condition -- older/weaker solenoids produce more upward trajectory variation (learned from Physics Debate).

Threshold tuning: Both sling threshold AND hit threshold should match. If they differ, animation/sounds trigger without physics or vice versa. Monster Bash testing: threshold of 1.5 was the sweet spot between too sensitive (1) and too insensitive (2) (learned from Monster Bash).

TargetBouncer

TargetBouncer adds realistic vertical bounce to standup target hits. The code redistributes ball velocity into a Z component.

Key constants: - TargetBouncerEnabled = 1 - TargetBouncerFactor = 0.7

Random multiplier (0.2-0.5) varies the bounce height. Only fires when ball.z < 30 (on playfield). Add targets/posts to a TargetBounce collection, then the TargetBounce_Hit(idx) sub calls TargetBouncer activeball, 1. Must be added to the bottom of the script.

The TargetBounce_Hit sub MUST include the (idx) parameter:

Sub TargetBounce_Hit(idx)
    TargetBouncer activeball, 2
End Sub

Without the parameter, the sub signature doesn't match and the bounce code silently fails (learned from VPW Example Table, nFozzy Physics Guide).

The Energy Debate

There is active disagreement on TargetBouncer implementation. iaakki's original code (from WRD's Funhouse) intentionally adds energy to create occasional air balls. apophis79 modified the code, which iaakki considers "broken." rothbauerw's position: "adding energy is really not correct, but may feel more correct" because target elasticity settings may warrant it. No perfect solution -- each implementation is a tradeoff (learned from Physics Debate).

Exclusion Zones

TargetBouncer should be excluded from objects near scoops. On STTNG, sleeves surrounding the Start Mission scoop had target bouncer enabled, causing balls to bounce upward instead of rolling into the scoop. Fix: comment out the target bouncer call for sleeves near scoops (learned from Star Trek TNG).

Drop Target Layback

Drop targets on real machines have a slight backward lean (layback angle) of 4-7 degrees. This causes the ball to bounce upward slightly on impact rather than straight back. Implementing this in VPX via the target's layback property produces more realistic ball behavior (learned from Physics Debate).

Bumper Strength Standards

Bumpers are generally set too weak in VPW tables. Strength of 13-15 is more realistic. Bumper collision radius should match the rubber skirt/ring, NOT the plastic cap on top. On RBION the bumpers were incorrectly sized to the plastic cap radius (45) -- correct radius was 38. The X-Men Gambit shot through bumpers was impossible until the radius was corrected (learned from Physics Debate, Ripley's Believe It or Not).

Reference nFozzy bumper settings from Game of Thrones: Force 9.5-10.5, Hit Threshold 1.6-2, Scatter Angle 2. Note: the 13-15 strength recommendation above is a general gameplay tuning guideline, while these nFozzy reference values are from a specific GoT build. The appropriate value depends on the table's era and physics setup.

Spinner Damping

Spinners lack a _Hit sub, so measuring hit velocity requires a workaround.

Trigger method: Add an invisible trigger before the spinner to capture activeball.vely + activeball.velx.

Timing method: Measure time between _Spin calls using gametime -- shorter intervals = faster spin. metated's code uses a SpinnerHit trigger to reset counters, then progressively increases damping after a calculated spin threshold based on spintime between first two spins. 4000 / spintime determines when to start adding damping (learned from Physics Debate).

Difficulty Slider Behavior

The difficulty level in table options changes slope (if SlopeMin/Max are different) and how much scatter is applied. It does NOT change ball mass -- that's a constant. If min and max table slope are set to the same value, difficulty still modifies scatter randomness. Flipper scaling via difficulty is "totally nonfunctional" per nFozzy's code review, but slope interpolation is active (learned from Physics Debate, Star Trek TNG).

The default difficulty of 20 produces significantly different physics than the intended 50-56 range. Always set difficulty to the intended midpoint (~56) before any physics tuning, otherwise all tuning work will be wrong when corrected later (learned from Star Trek TNG).

Mini Playfield Physics

For mini playfields with lighter/smaller balls: do NOT apply trajectory correction, but everything else should be fine. Mass and flipper strength are the two most important variables for feel. For lighter balls, use lower mass to be more responsive. Cirqus Voltaire uses a bigger ball with lower mass that just bounces around in a cage -- different considerations than a full mini playfield with flippers (learned from nFozzy Physics Guide).

Collidable Geometry Guidelines

Inlanes should always use walls for collision, never primitives. Collidable primitives are only for complex shapes where walls can't approximate the geometry. VPX walls have optimized collision detection that primitives don't benefit from. Walls are better than collidable primitives for physics -- each triangle face in a collidable primitive causes a physics calculation when the ball crosses it, leading to performance issues and strange ball behavior (learned from Physics Debate, Austin Powers).

For ramps: Use two separate meshes -- a high-poly visual mesh (non-collidable) for appearance and a simplified invisible mesh (collidable) for physics. The collidable mesh can be drastically simpler; flat planes with side walls are sufficient (learned from Stargate, Judge Dredd).

Duplicate collidable primitives: Having two collidable primitives overlapping in the same location causes choppy, stuttering ball movement as the physics engine fights between the two collision surfaces (learned from Fish Tales).

Normals direction: Collisions only occur when the ball hits a face with an outward-pointing normal. The ball passes straight through backfaces. For objects hittable from both sides, the mesh needs thickness with normals facing out on all surfaces (learned from Jokerz).

Foam Rubber Ramp Entrance Reshaping

Square foam sleeves at ramp entrances reject balls too easily because on real machines the ball leans against the rubber rather than bouncing off a flat face. Fix: reshape the foam rubber mesh to be more pointed/conical so balls can lean into it. Hard corners on rubbers behave strangely when ball presses against them at an angle. iaakki modified TWD ramp entrance geometry and it significantly reduced false rejections (learned from Physics Debate).

Playfield Glass as Physics Ceiling

VPX's built-in glass height setting does NOT act as a physical barrier. To simulate glass preventing ball flyover, add an invisible wall/ramp at the correct glass height. Tested measurements from real Firepower II: approximately 2 inches bottom to glass, approximately 4 inches top. Can add a glass hit sound for realism. The glass height also affects maximum ball trajectory height -- ramps that arc above the glass plane will have trajectories clipped (learned from TNA, Iron Man).

VPX Hit Detection Bug

VPX physics hit detection is inconsistent -- doesn't always register hits, especially with low-elasticity objects. Tested across 10.6, 10.7 with the same issue. iaakki created a 100% repro by removing default scatter and resetting angmom/vel values. Filed as GitHub issue #1266. Niwak pushed a fix in VPX 10.8.1 that improved but didn't fully resolve the issue. This affects any table using dampeners or hit events on rubber/wall objects (learned from Physics Debate).

Tilt Bob Simulation

Script-Based Prototype

iaakki prototyped a virtual tilt bob using a VPX ball in a collidable cup mesh to simulate real tilt bob physics -- the bob continues swinging after nudges, affecting future nudge tolerance. Forward nudges are more secure than sideways, matching real tilt rod orientation. Works differently for keyboard (single-direction press) vs Pinscape (shaking motion).

Native VPX 10.8.1 Implementation

VPX 10.8.1 includes a native tilt plumb simulator running in the core physics engine at 1kHz, superseding the script-based approach. It models a 3D Newtonian mass on a bar that can hit and bounce against a ring. Three nudge models: (1) Legacy -- direct force on balls, (2) Acceleration-based -- impulse to cabinet spring-mass model, (3) Velocity-based -- best quality, requires Pinscape firmware update. Settings: inertia factor and tilt threshold, adjustable per setup. LiveUI overlay shows dynamic plumb position when nudging (learned from Physics Debate).

Flipper Measurements Database

apophis79 purchased and measured an array of real flippers, documenting key dimensions in a spreadsheet. BorgDog later added Gottlieb flipper dimensions. Segmented ("carrot") flippers were introduced with Bally overhead-speaker series (Williams System 11 era). This is the reference for accurate flipper geometry in VPX tables across eras.

Reference: https://docs.google.com/spreadsheets/d/1MQBI9kpt6w-ti-vSD9WI53X-oYpSSZ7dyxwPIdFX9n4/edit

(learned from Physics Debate)

Lightning Flipper Dimensions and AddPt Indexing

Fish Tales uses lightning flippers (2.875" / approximately 73mm, vs standard 3" / approximately 76mm). When adding physics correction points via AddPt (nFozzy velocity correction along the flipper), the second parameter must be sequentially indexed (1, 2, 3...). Three points are typical: base, middle, and tip. Each point defines a velocity correction at that position along the flipper surface. Missing or incorrectly indexed points cause the flipper physics to apply wrong corrections, particularly visible on tip shots (learned from Fish Tales).

Leaf Switch vs Keyboard Polling Input Latency

Physical cabinet flipper button input method significantly affects flipper trick detection:

• KL25Z board with leaf switches: Limited to approximately 20ms minimum due to debounce (8ms) plus spring contact bounce. Occasionally misses fast taps entirely.
• PS/2 keyboard hack with gold leaf switches: Pure interrupt-driven (no USB polling), achieves 5-8ms tap detection with zero missed contacts.

For tap passes to feel natural, the sosramp parameter needs to be very low (approximately 0.5) to compensate for input latency. Players at 60 Hz are further disadvantaged because VPX can only register inputs once per frame (16.7ms) (learned from Fish Tales).

Ramp Entry Angle Impact on Ball Speed

Ramp friction set too high (e.g., 0.8, described as "velcro ramp") makes ramps nearly impossible to complete. Always check ramp friction values and unify physics using a single material (around 0.2 friction). A barely perceptible "speed bump" in a collidable ramp primitive profile can cause inconsistent ball behavior -- the fix was "absolutely fractional" but made the ramp feel consistent (learned from Austin Powers, Jokerz).

Elasticity Fall-Off ("metalfo")

The metalfo (metal fall-off) physics parameter controls how elasticity decreases at higher ball speeds. Without it, fast-moving balls bounce with the same energy ratio as slow ones, which is physically unrealistic.

• Purpose: Makes high-speed impacts "deader" -- the ball absorbs more energy on hard hits
• Effect: Ramp entries at high speed don't produce exaggerated bounces; ball settles faster after hard collisions
• Application: Apply to metal surfaces (ramps, wire guides, posts) where high-speed damping matters most

(learned from Iron Man)

Ramp Exit Spin Multiplier

The ramp exit spin multiplier in VPX can cause unrealistic ball behavior when exiting ramps -- the ball spins excessively and deflects unpredictably. Reducing the max spin multiplier from the default 70 to 50 produces more realistic ramp exit behavior where the ball rolls smoothly off the ramp rather than corkscrewing.

This is a global physics hack, not per-ramp configurable. It affects all ramp exits in the table, so the value must be balanced across all ramps (learned from Iron Man).

Ramp Propulsion Script

When ramp geometry makes shots unrealistically difficult, a targeted ball propulsion script at the ramp entrance can compensate without changing flipper strength:

Sub Sw36_UnHit()
    dim speed:speed = ActiveBall.VelY
    Controller.Switch(36) = 0
    If speed < -25 and speed > -32 Then
        speed = speed * 1.15
        If speed < -34 Then speed = -34
        ActiveBall.VelY = speed
    end if
End Sub

At the ramp entrance switch, if ball speed is in a marginal range (almost enough to make it), apply a 1.15x multiplier. Cap at -34 to prevent unnaturally fast ramps. Balls that are too slow or already fast enough are unaffected. Only use as a workaround for imperfect ramp geometry -- ideally fix the geometry (lower ramp height, adjust flipper angles, add missing gates) (learned from Hook).

Playfield Slope and Friction Calibration

Physics tuning methodology for accurate gameplay feel:

1. Measure real playfield slope (use the game manual as starting point; iPhone level app on the playfield surface for precision)
2. Match ball roll speed from a reference point against real machine video -- this calibrates slope + friction together
3. Tune flipper strength to match real shot difficulty
4. Fine-tune ramp friction last

Default playfield friction of 0.02 is far too low. Calibrated values for a Stern-era machine: 0.15-0.25 (learned from Iron Man). Ball roll speed must be calibrated first because flipper strength, ramp difficulty, and drain behavior all depend on it (learned from Stargate).

Set min and max slope to the same value during testing so you know exactly what slope you're using. The manual-specified slope may differ significantly from how real machines are actually set up (learned from Goldeneye, Stargate).

Under-Playfield Blocker Wall

Under-playfield blocker walls prevent the ball from sinking through the playfield mesh during cradling. The powerball (0.8x mass) on TZ is especially susceptible. Place the wall at -0.01 Z (just below playfield surface). Critical locations: plunger lane and flipper area. Full-table coverage is optional but shooter lane and flippers are mandatory. Good practice for all tables as a preventive measure (learned from Twilight Zone).

Playfield Mesh Loop Cuts

Loop cuts in the playfield mesh can cause balls to stick at standstill, particularly in the flipper area. When a ball is nearly stopped, it can "pick up" the loop cut edge and get trapped. Avoid loop cuts in the flipper area. Place a thin wall at height 0.01 over the affected area as a workaround. However, loop cuts ARE needed along long edges to prevent texture alignment drift -- the playfield graphic gradually shifts away from where it should be. Balance is needed: subdivide long edges but avoid subdividing near flipper areas (learned from Batman DE, Star Trek TNG).

VP Unit Conversion Formula

Standard conversion factors: - 50 VP units = 1.0625 inches - 47.059 pixels per inch (the VPX Dimension Manager rounds this to 47, which is imprecise for alignment work) - Ball diameter: 50 VP units - Ball radius: 25 VP units

Standard playfield dimensions: - WPC standard: 20.25" x 46" (952 VP units wide) - Williams widebody: 23" x 46" - Gottlieb System 1: 20.25" x 42"