This is an old revision of the document!
Real-Time Environments
Screen Space
Core Concept
Screen Space techniques operate directly in the final image space (the screen), rather than in object or world space.
Instead of computing how light interacts with geometry, they reuse what the camera has already rendered and manipulate it to produce the desired visual result.
→ If it is not visible on the screen, it does not exist.
Mental Model
Three main spaces to think in:
- World Space → physical simulation, lighting, PBR
- View Space → camera-relative tricks (Matcap, etc.)
- Screen Space → pixel-perfect control of final image
Screen Space sits at the top of the stack:
→ Not simulation → Not approximation → Final perception control
Origin
Screen Space techniques emerged in real-time rendering (mid 2000s → early 2010s) as a response to performance limitations.
Full physical simulation (ray tracing, global illumination) was too expensive for real-time systems.
Solution:
→ Only compute what the camera already sees → Reuse existing rendered data → Fake the rest
This led to the rise of:
- SSAO (Ambient Occlusion)
- SSR (Reflections)
- Screen Space shadows and refraction
Core Principle
All Screen Space techniques share the same law:
Use the rendered image as the primary data source → operate in screen coordinates → trade physical accuracy for performance and control
Strength:
- extremely fast
- visually convincing
Weakness:
- blind to anything off-screen
- can break at edges or occlusions
Screen Space Materials
A Screen Space material ignores object-based shading and instead displays content aligned with the camera view.
Think of it as:
→ geometry becomes a canvas → the screen becomes the reference
Properties:
- Not affected by lighting
- Not affected by environment maps
- Stable regardless of object orientation
- Perfect alignment with output
Typical usage:
- projection mapping (exact output match)
- overlays / UI in 3D space
- compositing layers
- debug / data visualization
Key Consequence
color = texture(screen_x, screen_y)
The material is evaluated per pixel on screen, not per surface in space.
→ UVs become secondary → normals become irrelevant → lighting is bypassed
Screen Space Reflections (SSR)
SSR uses screen space to approximate reflections.
Instead of tracing rays in 3D:
→ sample the already rendered image → reuse visible pixels as reflection data
Limitations:
- cannot reflect off-screen objects
- breaks at screen edges
- unstable in fast motion
Relation to Screen Space materials:
- same coordinate system (screen space)
- same dependency on visible data
- different purpose (effect vs display)
Other Screen Space Techniques
Common siblings:
- SSAO → fake contact shadows using depth
- Screen Space Refraction → distort background using screen data
- SSGI → approximate bounced light
- Screen Space Shadows → cheap shadow approximation
- Screen Space Decals → project textures after rendering
All share:
→ operate on the final image → avoid expensive world simulation
Real-Time Philosophy
Screen Space is part of a larger doctrine:
Reality → Simulation → Approximation → Screen Space → Perception
In real-time systems:
→ simulation is expensive → approximation is common → screen space is strategic control
Practical Use (Immersive / Media Servers)
In immersive environments, Screen Space shifts from optimization to precision.
Used for:
- projection-aligned rendering
- predictable visual output
- compositing in 3D pipelines
- stable overlays and UI elements
Key advantage:
→ What you see = what you output
Limitations
- breaks physical realism
- flat appearance if misused
- dependent on camera view
- no depth awareness beyond visible data
Use when:
→ control > realism
Final Rune
Screen Space techniques do not simulate the world.
They control what the audience perceives, using only what is already visible.
→ Geometry becomes support → The screen becomes truth