Render Pipelines
For a new LABO project, choose Unity's Universal 3D template. This uses the Universal Render Pipeline (URP).
URP is the safest default because it can target desktop computers, phones and tablets, the web, PC-connected headsets, and standalone headsets. It is also the path used by the LABO Package setup guide.
Choose HDRP only when all three statements are true:
- the experiment will run only on supported desktop-class hardware;
- an HDRP-only visual feature is necessary for the research question; and
- you have tested the complete experiment on the exact hardware you will use.
Use Built-in mainly when maintaining an existing project that already depends on it.
What is a render pipeline?
A Unity scene contains cameras, lights, materials, text, images, and 3D objects. The render pipeline is the set of rules Unity uses to turn that scene into the pixels a participant sees.
Think of the scene as the ingredients and the pipeline as the recipe for producing the final image. The ingredients can stay the same while the lighting, shadows, reflections, and final pixels change.
Two Unity terms appear often on this page. A material describes how a surface should look. A shader is the code that calculates that appearance. Post-processing means filters applied to the camera image near the end, such as bloom, colour adjustment, or depth of field.
The pipeline therefore affects:
- which computers, phones, and headsets can run the experiment;
- which lighting and visual effects are available;
- how materials and custom shaders must be authored;
- how much rendering work the device must complete for each frame; and
- which settings must be recorded to reproduce the visual stimulus.
It does not define your trial order, response collection, data logging, or sensor streams. Those are separate parts of the experiment.
Why choose it before building the experiment?
Unity can convert or rebuild parts of a project for a different pipeline, but the pipelines do not use identical materials, shaders, lighting models, or post-processing systems. Unity consequently recommends choosing early and warns that a late change can take substantial time. URP and HDRP also cannot be active at the same time. See Unity's pipeline selection guide.
For a researcher, a late pipeline change is more than a software inconvenience. It can change the appearance of the stimuli and invalidate a pilot-to-main-study comparison unless the new build is revalidated.
The three choices
| Pipeline | Plain-language description | Best fit | Main reason not to choose it |
|---|---|---|---|
| URP | Unity's current general-purpose pipeline | New LABO projects; desktop, mobile, web, and most XR studies | A small set of high-end lighting features is available only in HDRP |
| HDRP | A high-fidelity pipeline for powerful desktop and console hardware | Desktop-only studies in which advanced lighting or rendering is part of the method | No Android, iOS, Mobile VR, HoloLens, or WebGL support |
| Built-in | Unity's older general-purpose pipeline | Existing projects that already use Built-in materials or shaders | It is not the LABO setup path, and moving later can require asset conversion |
Platform support in Unity 6.3 LTS
The following is Unity's published support matrix, shortened to the platforms most relevant to experiments:
| Target | Built-in | URP | HDRP |
|---|---|---|---|
| Windows, macOS, or Linux | Yes | Yes | Yes |
| Android | Yes | Yes | No |
| iOS | Yes | Yes | No |
| Desktop VR | Yes | Yes | Yes |
| Mobile or standalone VR | Yes | Yes | No |
| HoloLens | Yes | Yes | No |
| WebGL | Yes | Yes | No |
Source: Unity's render-pipeline feature comparison.
HDRP's desktop Yes still has hardware conditions. Unity requires a compute-shader-capable GPU and does not support OpenGL or OpenGL ES for HDRP. Its documented desktop paths are DirectX 11/12 on Windows, Metal on macOS, and Vulkan on Windows or Linux. See HDRP system requirements.
A Yes means the Unity pipeline can target that platform. It does not guarantee that every headset feature, XR plug-in, third-party asset, or LABO package version supports the same configuration. Confirm the exact device and required APIs before freezing the study design.
Standalone and PC-connected XR are different deployments
This distinction is easy to miss when you are new to Unity.
Standalone XR means the application is installed on the headset and rendered by the headset's own processor. Many common standalone headsets are Android and Mobile VR targets; HDRP supports neither category. Check the exact target for less common standalone devices rather than inferring compatibility from the word “standalone.”
PC-connected XR means the experiment is a desktop application rendered by a computer. The headset supplies tracking and displays the result. Unity classifies this under Desktop VR, which all three pipelines support.
A study can also use a separate computer to collect physiology, eye tracking, motion capture, or other data while the experiment runs standalone on the headset. That computer is a data source or recorder, not the renderer. Its presence does not make the headset build PC-connected.
This matters operationally. A PC-connected study needs a sufficiently powerful and consistently configured computer at every data-collection site. A standalone study has a smaller equipment footprint, but a tighter rendering budget.
A practical decision table
| Your study | Choose | Why |
|---|---|---|
| Questionnaire, reaction-time task, images, text, or ordinary 3D scenes | URP | It provides the required rendering and preserves future device options |
| Phone or tablet study | URP | HDRP does not support Android or iOS |
| Standalone-headset study | URP | HDRP does not support Mobile VR |
| Study may later move between desktop, mobile, and XR | URP | One pipeline covers all of those targets, although each target still needs its own build and validation |
| Existing Built-in project | Usually keep Built-in initially | Avoid introducing visual changes unless migration provides a clear benefit |
| Desktop-only study requiring an HDRP-only cue | Consider HDRP | The additional feature may justify the narrower deployment options |
| You are not sure | URP | It closes the fewest deployment paths |
When might HDRP be scientifically necessary?
URP supports the visual elements used in most experiments: text and UI, images, ordinary 3D materials, directional/point/spot lights, shadows, baked lighting, reflection probes, HDR rendering, colour adjustments, bloom, ambient occlusion, and depth of field.
HDRP adds capabilities that can matter when the rendering method is part of the experimental manipulation. Examples in Unity's comparison table include:
| Research need | What HDRP adds | Decision question |
|---|---|---|
| Lighting authored in real-world-style units | Lux, lumens, candela, nits, and physical-camera exposure controls | Do these controls help define the virtual scene, or do you actually need calibrated light from the physical display? |
| Fog or atmosphere is a controlled depth cue | Advanced volumetric and local fog systems | Is simple fog sufficient, or is volumetric scattering itself part of the hypothesis? |
| Skin appearance is the stimulus | Subsurface-scattering models intended for skin | Would ordinary physically based shading remove or distort the cue being studied? |
| Mirrors or highly reflective surfaces are central | Planar, screen-space, and supported ray-traced reflections | Is reflection behaviour a dependent or independent variable rather than decoration? |
Do not choose HDRP simply because the name sounds more accurate. Visual fidelity and measurement validity are different things. A more complex image can add uncontrolled cues, reduce frame-rate stability, and make deployment harder without improving the construct you intend to measure.
Research-design issues the pipeline cannot solve for you
1. Absolute luminance and colour require physical calibration
HDRP's physical light units describe lights and emissive surfaces inside the virtual scene. They do not guarantee that a monitor or headset emits the requested number of candelas per square metre at the participant's eye.
The final output also depends on the display, brightness setting, colour profile, transfer function, HDR mode, tone mapping, ambient light, viewing geometry, and potentially the headset runtime. If luminance, contrast, or colour is a controlled variable:
- set and lock the complete rendering configuration;
- measure the final stimulus on the actual display with appropriate equipment;
- derive and validate the mapping from Unity values to measured output;
- repeat the check for each device or site; and
- report the calibration method and measured range.
This applies to URP, HDRP, and Built-in. HDRP can make a virtual lighting model easier to author in physical units, but it does not replace display calibration. For an accessible calibration overview, see PsyCalibrator.
2. Camera settings are not a substitute for visual-angle control
Unity's pipeline comparison says that URP's Physical Camera affects field of view, while HDRP can also connect physical-camera settings to exposure, bloom, and depth of field.
In URP, focal length, sensor size, lens shift, and Gate Fit can help match the framing of a real camera. URP depth of field is configured through a Volume effect with its own focus distance, aperture, and focal-length controls.
Unity's general comparison says the URP Physical Camera affects field of view only, but the dedicated URP camera page also says its lens properties directly affect depth of field. Because those official pages conflict, do not make a scientific manipulation depend on the assumed link. Set the Volume values explicitly and validate the rendered result in the exact Unity version used for the study.
For a monitor study, visual angle additionally depends on display size, resolution, viewing distance, and participant position. For an XR study, the headset model, eye relief, display optics, render scale, and per-eye projection matter. Record those properties; a Unity focal-length value alone is not a complete stimulus specification.
3. Frame rate is part of stimulus timing
A display presents images at discrete refreshes. The nominal time available for each refresh is:
| Refresh rate | Time per refresh |
|---|---|
| 60 Hz | 16.67 ms |
| 72 Hz | 13.89 ms |
| 90 Hz | 11.11 ms |
| 120 Hz | 8.33 ms |
If the application misses a presentation deadline, a visual change may appear one or more refreshes later than intended. In XR, the compositor may reproject or retain an earlier application frame, so an application timestamp is not automatically the same thing as photon onset at the display. Unity describes these fallback behaviours in VR frame timing.
The render pipeline contributes to the workload, but it does not determine performance by itself. Scene complexity, transparent overdraw, shadows, post-processing, scripts, device temperature, and background processes can all matter. There is no valid rule that a particular pipeline will meet your timing requirement without testing the actual paradigm.
For every target device:
- profile a built player—the exported application that participants will run—not only the Unity Editor;
- test the busiest trial or scene, not only an empty room;
- confirm the intended refresh rate and frame-time headroom;
- record frame-time distributions and dropped or missed frames during pilots; and
- repeat after any change to assets, quality settings, Unity version, XR runtime, or device firmware.
Unity's Frame Timing Manager can report CPU/GPU frame-timing data with a four-frame delay. It cannot by itself prove when light reached the participant. If sub-frame visual onset or synchronization with EEG, eye tracking, motion capture, or physiology is important, validate the end-to-end system with a photodiode or another appropriate external measurement. Hardware approaches such as the Stimulus Onset Hub illustrate why software timestamps and physical onset should be treated separately.
4. Rendering features can become hidden confounds
Keep rendering settings constant across participants, conditions, devices, and sites unless they are deliberately manipulated. Pay particular attention to:
- automatic exposure and tone mapping;
- dynamic resolution and render scale, which can change the number of pixels Unity renders;
- fixed or eye-tracked foveated rendering;
- anti-aliasing method;
- shadows and real-time reflection settings;
- depth of field, motion blur, film grain, and colour adjustments; and
- quality-level overrides.
For example, foveated rendering saves work by rendering some regions—usually the periphery or areas away from the current gaze point—at lower detail. That may be a useful optimization, but it can interact with peripheral stimuli, contrast, gaze-contingent tasks, or visual-search measures. Treat it as part of the apparatus, not as an invisible implementation detail.
Unity also advises VR developers to avoid Lens Distortion, Chromatic Aberration, and Motion Blur because they can contribute to nausea or disorientation, and suggests vignette for fast motion. See post-processing in URP for VR. For research, the stronger rule is to include an effect only when it serves the task and has been piloted for both comfort and measurement consequences.
What to freeze and report for reproducibility
Before collecting data, archive the build and record at least:
| Category | Record |
|---|---|
| Software | Exact Unity editor version, LABO version, Packages/packages-lock.json, build identifier or commit |
| Rendering | Pipeline package version, pipeline asset and settings, active Quality level, colour space, HDR state, graphics API |
| Image settings | Resolution, render scale, dynamic resolution, anti-aliasing, post-processing, exposure, tone mapping, foveation |
| Hardware | Computer/GPU or headset model, display model, connection mode, refresh rate, firmware/runtime versions |
| Calibration | Brightness and colour settings, measurement device and procedure, measured luminance/colour range |
| Timing | Target refresh rate, observed frame-time distribution, missed-frame rule, external onset/synchronization validation |
| Sites and conditions | Any setting or hardware difference, plus evidence that the stimulus remained equivalent |
Keep the exact player build used for data collection. Treat an editor, package, firmware, driver, or pipeline change after piloting as an apparatus change that requires targeted revalidation. Broader VR reproducibility guidance is available in the open-science protocols described by van Zelderen and colleagues.
LABO's supported setup path
For a new experiment, follow the Universal 3D / URP setup path in this documentation.
Unity platform support and LABO feature support are separate questions. If you are bringing an existing Built-in or HDRP project into LABO, first make a small compatibility build that exercises every feature your study needs: participant cameras, tracking visuals, post-processing, data capture, target-device APIs, and a representative trial. Do this before migrating the full study or recruiting participants.
Changing pipelines later
Changing is possible, but it is a migration rather than a harmless project setting.
Unity's Render Pipeline Converter can convert several Built-in assets and settings to URP. Unity warns that the conversion changes the project irreversibly, and its material converter does not handle materials with custom shaders. The tool is specifically documented for Built-in-to-URP conversion; do not assume it will translate a complete URP project to HDRP, or the reverse. See Render Pipeline Converter.
Before attempting a migration:
- create a separate version-controlled branch or complete project copy;
- inventory custom shaders, materials, post-processing, and camera settings;
- convert a representative scene first;
- compare screenshots and measured stimulus properties against the original;
- rerun performance, timing, calibration, and device tests; and
- never replace the validated study build until the migration passes those checks.
Check which pipeline a project is using
- Open Edit → Project Settings → Graphics.
- Look at Default Render Pipeline. A URP or HDRP project normally names a pipeline asset there.
- Then open Edit → Project Settings → Quality and check the Render Pipeline Asset for the active quality level.
The Quality setting takes precedence over the Graphics default. If the active Quality level has no override, Unity uses the Graphics default. If neither location contains a pipeline asset, Unity uses Built-in. Unity documents this precedence in Change or detect the active render pipeline.
Version used for this page
This page was verified against Unity 6.3 LTS (6000.3) on September 2, 2026. Unity lists 6.3 as the current LTS and supports it through December 2027; Unity 6.0 LTS is supported through October 2026. See Unity 6 release support.
For a study, “Unity 6” is not a sufficiently precise version record. Pin the exact editor patch and package versions used to build the validated player.
Primary technical sources
- Choose a render pipeline
- Create a new project that uses URP
- Render-pipeline feature comparison
- HDRP system requirements and compatibility
- HDRP physical light units
- URP camera reference and URP Physical Camera reference
- URP post-processing guidance
- VR frame timing and foveated rendering
- Render Pipeline Converter
- Active render-pipeline precedence
- Unity 6 release support
Next
Continue to Project Setup to configure the build target and, for XR experiments, the headset and tracking system.