Transparent Ramps, Plastics & Glass¶

Transparent elements are among the most technically challenging aspects of virtual pinball rendering. They require careful coordination between 3D modeling, baking workflows, VPX material setup, and refraction probe configuration. This guide consolidates everything learned across dozens of VPW table builds about making ramps, plastics, glass, and other see-through elements look convincing without destroying performance.

Quick Start

One refraction probe per depth layer -- overlapping transparent objects at different heights each need their own probe. Non-overlapping objects can share one
Refraction thickness: Default 10 is too much. Use 1-4 for plastics, 5 for thin ramps
Set render probe roughness to 0 -- up to 40% FPS improvement, and non-zero roughness causes white flashing in VR
Transparent objects: uncheck "Hide Parts Behind" (depth masking). Opaque objects: keep it checked
Transparent bounce count in Blender must be 16-32 (Render > Light Paths). Low values produce cloudy shadows
Plastics must use PNG with alpha -- JPG kills transmission. Ramp UV unwrap must be done AFTER applying Solidify modifier

Transparent Ramp Baking Approaches¶

Three distinct approaches have emerged for rendering transparent ramps, each with different tradeoffs around viewing angle fidelity, visual quality, and workflow complexity.

POV-Dependent Projected Texture¶

The simplest approach renders the ramp from the table's camera point of view, capturing refraction, glossiness, and environmental reflections in a single flat texture. The ramp primitive in VPX displays this pre-baked texture, which looks correct from the bake camera angle but breaks at other viewing angles. First documented during the Godzilla (Sega) build, this method was also used on Guns N' Roses. For wire and metal ramps, the mesh must be split into pieces to avoid overlapping surfaces from the camera's perspective. The technique works well for desktop-only tables but is problematic in VR where the player moves freely.

POV-Independent UV Unwrapped¶

UV-unwrapped ramp textures work from all viewing angles but may lack the glossy quality of projected textures. As documented during the Godzilla (Sega) build, Blender 3.6's "bake from camera" with AI denoise eliminates the need to split ramps and renders back-faces nicely for VR. The UV unwrap must be done after applying any Solidify modifier on the ramp mesh -- a lesson learned painfully on Creature from the Black Lagoon, where an unapplied Solidify caused the bake to render only the ramp edges.

Hybrid Approach¶

Benji084 developed a hybrid method combining both techniques, first applied on Godzilla (Sega):

Run the toolkit batch with POV-dependent green material plus environment glossiness
Separately bake the ramp UV-unwrapped with a mostly-transparent texture
Import the ramp as two meshes (edges plus floor/sides)
Apply separate VPX materials and refraction probes to each

The key insight: always keep environment glossiness enabled during baking. Without it, ramps look flat and lifeless. On colored ramps like those on Guns N' Roses, the tint creates attractive lightmap spillover onto sideblades.

Ramp Material Setup in Blender¶

Dual Material Technique¶

For transparent plastic ramps in Blender toolkit tables, a technique developed for Last Action Hero uses two materials on the ramp geometry. Material 1 is a glossy transparency with a grain of white diffuse, applied to flat areas (bottom, sidewalls, top surface). Material 2 is a glass material with refraction and a grain of white diffuse, applied to bevel edges and the ramp perimeter (use the bevel node to make these more visible). The ramp should be split into sections to avoid transparency overlap issues.

Transparent Bounce Count¶

When rendering plastic parts in Blender Cycles, the transparent max bounces setting under Render Properties > Light Paths must be increased to 16-32. First identified during the Last Action Hero build, lower values produce cloudy, dirty shadows through transparent parts. This single setting was responsible for ugly ramp renders that persisted until the root cause was traced by comparing render settings against Iron Man.

Ramp Visibility Adjustment¶

Three approaches exist for adjusting how visible a transparent ramp appears, documented during the Creature from the Black Lagoon build:

Bakemap alpha overlay: Add a low-opacity grey background layer (5-8%) to the bakemap EXR in GIMP. Eight percent worked well for CFTBL; twenty percent made ramps look opaque. Only affects the bakemap, not the lightmap.
Blender material alpha: Adjust transparency in the Blender material itself to avoid manual post-processing on every bake.
Refraction tint: Darkening the refraction tint parameter in VPX makes ramps more visible. Somewhat hacky but provides immediate feedback in the VPX editor.

Single-digit percentages is all that is needed. The difference between "invisible" and "too opaque" is remarkably narrow.

SSS for Aged Ramps¶

Adding Subsurface Scattering to ramp materials creates a "slightly less clear glass" look matching real machine ramps that have become milky with age. First applied on Creature from the Black Lagoon, where reference photos showed the real ramps were noticeably less clear than fresh acrylic, with ramp light strings bleeding into the material.

Refraction Probes in VPX¶

VPX 10.8 introduced native refraction probes that handle light bending through transparent objects at runtime. The setup and performance implications were extensively documented across many table builds.

Basic Setup¶

Refraction probes are created in VPX's Render Probe Manager (not the toolkit side). Each transparent primitive gets a probe assigned in its properties along with a thickness value. As documented during the Police Force build by apophis79 and niwak:

Thickness controls light-bending intensity: 5 for thin plastics, 10-20 for thick objects
Roughness in probe settings controls fogginess of the refraction
Edge opacity in VPX transparency settings can be turned down for a cleaner look

One Probe Per Depth Layer¶

The most critical rule, established across multiple builds: overlapping transparent objects at different heights each need their own refraction probe. Using a single probe for overlapping transparent objects causes one layer to disappear entirely. This was first documented on Flash Gordon and confirmed on Fish Tales.

Non-overlapping transparent objects -- two ramps that do not cross over each other -- can and should share a single probe for better performance.

Refraction Thickness Values¶

The default refraction thickness of 10 is almost always too much. Across multiple builds, builders converged on lower values:

Medieval Madness: thickness 4 for ramps, with iaakki finding 1-2 works for most plastics
No Fear: lower values (1-4) preferred, with default 10 producing an overly "dirty" look
Police Force: thickness 10 for the LOTR sword (thick glass), but 5 for thin plastic ramps

Performance Impact¶

Removing ramp refractions on Johnny Mnemonic reduced GPU load from 100% to 90%, making the table playable on a GTX 1060 at 4K 60Hz. On Fish Tales, removing roughness from render probes yielded up to a 40% FPS improvement. Flupper1 noted during the Fish Tales build that using multiple refraction probes was "also a bad thing" for performance beyond just roughness.

For user-facing tables, the F12 options menu should expose refraction settings so users can adjust for their hardware, as implemented on Fish Tales and Johnny Mnemonic.

Refraction Probe Artifacts¶

When a single transparent primitive spans multiple depth levels (e.g., a ramp decal layer passing both above and below other ramps), refraction probes produce ghost/doubling artifacts. Documented during Johnny Mnemonic, the fix is to split the primitive into separate meshes at depth transitions, then only apply refraction probes to sections at consistent depth. Sixtoe split JM's ramps into four pieces for this purpose.

Wire Ramp vs Plastic Ramp Rendering¶

Wire ramps and plastic ramps require fundamentally different rendering approaches.

Wire Ramps¶

Wire ramps were first rendered to a high standard using Blender with Octane renderer on F-14 Tomcat, producing what the community described as "the best looking wires I've ever seen." The key is that Octane provides physically accurate metal reflections and thin-geometry rendering that standard VPX ramp objects cannot achieve. The result is imported as mesh primitives with baked textures, replacing VPX ramp objects for visuals while separate invisible VPX ramps handle physics.

Wire ramp polygon counts are a known performance concern. On Spider-Man, wire ramps were reduced from 70K to 17K triangles with no visible difference. On Lethal Weapon 3, high-poly wire ramp meshes caused multiball stuttering -- the performance issue is exponential with overlapping alpha-blended meshes, as a 500K mesh multiplied by five overlapping layers (parts, GI, lamps, flasher lightmaps) equals 2.5M effective triangles.

Plastic Ramps¶

Plastic ramp rendering has evolved significantly. The pre-toolkit approach on Cactus Canyon used Flupper's vertex painting in Cinema 4D to create areas of varying transparency, with vertex-painted alpha channels controlling where refraction occurs. This produced more controlled results than uniform transparency but predated VPX 10.8's native refraction support.

For toolkit tables, the edge splitting technique documented on Police Force by benji084 produces excellent results: bake the ramp material with minimal diffuse, add thin white strips along edges using fake RGB splitting, then let VPX's refraction probe handle the light bending. Material settings: Edge Opacity 0.5, Transparency Thickness 1, Refraction Thickness 10, Refraction Roughness 2.

Ramp Geometry Cleanup in Blender¶

VPX-exported ramp geometry always has unmerged vertices -- this is a VPX export limitation, not a modeling error. The standard cleanup procedure, documented during the Congo build:

Merge by distance (M > by distance) to weld unconnected vertices
Remove internal faces that corrupt material rendering
Add subdivision modifier for smoother curves, but add a bevel modifier BEFORE subdivision (per Flupper's tutorial ramp workflow)
Clean UV mapping after geometry fixes

When trying to bevel edges on plastics exported from VPX, the mesh has duplicate vertices that prevent bevel from working. As documented during Tron, the fix is to merge vertices by distance first in Blender edit mode, then the bevel modifier works correctly.

Transparent Playfield Elements¶

Windows Between Levels¶

Multi-level tables like Haunted House present unique transparency challenges. The playfield window between the main and lower playfields provided an opportunity for backglass reflections visible through the playfield. However, sixtoe warned that "fake reflections look bloody awful in VR, always." A better approach is adding a dust/dirt layer using a flasher with opacity around 200-250 to sell the glass material without over-relying on reflections.

Under-Playfield Visibility¶

For tables where elements beneath the playfield should be visible, the playfield mesh needs careful handling. As documented on Blood Machines, the playfield_mesh primitive can have holes cut with beveled edges, allowing balls to fall through to under-playfield mechanisms. On Monster Bash, static rendering on transparent/semi-opaque playfield objects causes lights to "swim" (shift position when moving head in VR). The fix is setting affected objects to active rendering, though this costs performance.

Depth Masking for Transparent Objects¶

Transparent objects should have "Hide Parts Behind" UNCHECKED in VPX (no depth masking). Opaque objects should have it CHECKED. This was clearly articulated by niwak during the Creature from the Black Lagoon build: depth masking on a transparent object is "usually a bug." The toolkit auto-sets this based on the Opaque property.

In standard rendering engines (Unity, Godot), every transparent part has depth masking disabled by default. VPX handles the playfield differently for backward compatibility reasons.

The VPX 10.8 "hide parts behind" feature, documented on Police Force, must be UNCHECKED for transparent/refractive objects or the object will hide parts of itself where the mesh curves behind other sections (self-overlapping geometry).

Depth Bias for Transparent Overlapping Elements¶

Depth bias controls rendering order for overlapping primitives and is critical for stacked transparent elements. The system works counter-intuitively, as documented on Batman DE: the element wanted on top needs the biggest negative number (e.g., -10000), and elements underneath need positive numbers.

For the ON/OFF insert primitive system used across many tables, standard depth bias values were established during the Indiana Jones build: ON primitives at depth bias 0, OFF primitives at depth bias 30. These values can reset after VPX crashes or version changes, requiring manual verification.

On Stargate, apophis79 documented that pure black (#000000) areas break lighting calculations. Use at minimum RGB(10,10,10) for dark areas to maintain proper light transport through transparent elements.

Glass Reflections: The "Mayo" Technique¶

"Mayo" (glass reflections/smudges) simulates the imperfect glass surface above the playfield. First documented by iaakki during the Godzilla (Sega) build, the implementation uses flasher objects with very low intensity positioned at glass height above flasher locations. Per-flasher intensity is controllable via script (e.g., f6_mayo.intensityscale = p * 0.5).

The technique was refined on No Fear, where placement must be carefully tuned to avoid cutting through nearby ramps or metal parts. On Metallica, iaakki refined mayo to use exponential falloff (level^2 or level^3) so the bloom disappears faster as distance from the light source increases, creating more dynamic lighting. Mayo should always be optional in the F12 menu.

The effect simulates fingerprints, smudges, and light catching on real glass -- every imperfection added brings realism.

Glass Dust Effect¶

A complementary technique for transparent covers was documented on Bad Cats by tomate80: add a flat plane primitive over the glass with a dust texture. The material uses the color channel mapped to texture color and the opacity channel mapped to texture alpha. Source textures from ambientcg.com (public domain PBR materials). This tells the viewer "something is there" without baked reflections being too much.

Plastic Scanning and Modeling¶

Scanning Challenges¶

Scanners work excellently for playfield surfaces but struggle with plastics due to their transparency and depth, as noted during the Earthshaker build. Plastics may need rescanning with alternative approaches or be redrawn entirely.

SVG Trace Workflow¶

Flupper1's method for creating plastic primitives, documented on Judge Dredd: trace the plastic shape in Inkscape as SVG paths, import into Blender, extrude to give thickness, apply textures. This produces cleaner geometry than freehand modeling.

The same workflow was applied on Simpsons Pinball Party: draw plastics in Illustrator as vector paths, export as SVG, import into Blender as curves, convert curves to mesh, extrude to correct thickness, UV unwrap and apply texture. Compound paths (holes in plastics) must be properly set up before SVG export.

Plastic Refraction in Octane¶

A pre-toolkit technique from Star Wars DE by kingdids: model the clear plastic shape with a small bevel for edge thickness, create a separate double-sided decal plane positioned slightly submerged below the plastic surface, and enable Fake Shadows/Caustics. The double-sided decal creates a fake refraction effect as light passes through the plastic above it.

Plastics Rendering¶

Plastics require careful material handling. On Bad Cats, benji084 documented that plastics depth/thickness effect requires three render passes composited from the camera's point of view -- the effect must be baked rather than done as separate layers, because camera angle differences cause misalignment between layers.

For toolkit tables, plastic textures must be PNG with alpha channel -- JPG kills transmission, as documented on Scared Stiff. Simply renaming a JPG to PNG is insufficient; the image needs proper alpha transparency data.

Stacked Transparent Elements and Performance¶

Transparent elements are among the most expensive rendering features in VPX. Niwak identified "limit non-opaque parts" as the number one performance recommendation for toolkit tables, documented during the Police Force build.

On Bad Cats, overlapping refractions (e.g., bumper caps near each other) caused more performance issues than single refractions. Removing refractions from bumper caps had more performance impact than removing them from ramps. On Tron, VPX F11 performance stats showing "transparent elements" consuming 50% of frame time indicated too many overlapping transparent objects.

The bumper cap transparency technique from Police Force uses two separate primitive meshes (inner dome + outer dome), each with its own refraction probe. This two-mesh approach by Flupper1 provides realistic translucency but doubles the transparent surface count per bumper.

Z-Fighting Fixes¶

Z-fighting between transparent elements and adjacent surfaces is a persistent issue. Several fixes have been documented:

Scale trick: When two primitives occupy the same plane, scale the opaque (bottom) primitive to 99.99% of its original size. This creates a sub-pixel depth offset that eliminates z-fighting without visible geometry change. First documented by niwak on Iron Man, this is simpler than depth bias and works universally across rendering backends.
Playfield depth bias: Setting the playfield primitive's depth bias to -500 fixes z-fighting between the playfield surface and objects sitting on it, as documented on Police Force.
Insert z-position: Set insert primitive z-position to -0.1 (not 0) to prevent z-fighting with the playfield surface, per Goldeneye.
Ball shadow height: Ball shadow primitives at exactly Z=0 cause z-fighting. Set to 1.01 VP units, per Earthshaker.

SSR (Screen-Space Reflections) on Ramps¶

Screen-space reflections on ramps were largely deprecated with the move to the toolkit pipeline. On Bad Cats, apophis79 noted that for toolkit tables in VPX 10.8, "no need for SSR." Render probe roughness on playfield reflection probes causes white flashing in VR, as documented on Breakshot and Defender. The fix: create two render probes -- one with roughness for desktop, one with zero roughness for VR.

Render Probe Roughness Performance¶

Render probe roughness (blur function) is the single most impactful performance setting for transparent elements. First measured on Fish Tales, confirmed on Breakshot:

Setting roughness to 0 for all render probes can yield up to 40% FPS improvement
The blur function has known bugs: white flashing on playfield, ghosting in VR (GitHub issue #939)
Refractions without roughness have minimal performance impact
This appears to be a DX9 renderer limitation

The pragmatic rationalization from apophis79: "It's more realistic for there to be no roughness if the table was recently clear coated."

Transparent Shadow Fix in Blender¶

Transparent plastics in the toolkit's Blender scene cast opaque shadows by default, which darkens the playfield beneath them unrealistically. Niwak's fix, documented during Iron Man, uses Blender's shader node system: add a Light Path node, connect the Is Shadow Ray output to a Mix Shader, and mix between the normal plastic shader and a Transparent BSDF. When a shadow ray hits the plastic, it passes through transparently instead of casting a dark shadow. This is critical for realistic lighting under plastic ramps and protectors.