All content in this course uses:

Creating Believable Visuals

This guide looks at the fundamental steps for setting up a good baseline for believable visuals. The advice in this guide is provided by the Spotlight Team at Unity. The Spotlight Team help developers and content creators achieve the desired look and quality for their projects. They hear stories from across the industry, and can identify the common issues that customers face. Questions that often arise when making a 

are “How do we build to a fairly realistic standard visual?” and “How do we make a 

Light, texture, scale, and material all need to work together to make digital content look real. With massive amounts of features, functions, options, properties, systems and variables to tweak, you could ask “Where do I start?” and “In what order do I proceed?”. This guide aims to answer these questions.

Spotlight Tunnel Sample Project

This step contains supplementary information for the 

 guide. While the general concepts in that guide still apply, this page contains updated guidance on converting a similar project to the Universal Render Pipeline (URP) and the High Definition Render Pipeline (HDRP), and highlights some key differences between Unity’s render pipelines.

Note that URP and HDRP are in active development, and new features are frequently added. See the latest versions of the 

Here are example projects for each render pipeline. You can download these to understand how to create similar visual effects in the different render pipelines, and to explore the different settings:

Spotlight Tunnel using the Built-In Render Pipeline

Converting your project from the Built-in Render Pipeline to URP or HDRP

Before you convert a project from the Built-in Render Pipeline, you should carefully read this page in full.

You should then perform these steps in order:

Make a backup of your existing project before upgrading.

It is risky to upgrade your version of Unity and change your project’s render pipeline at the same time. If you need to do both, upgrade your project to the new version of Unity first, and then switch to a new render pipeline. This allows you to fix any issues with the upgrade and ensure you have the correct package versions.

2. Removing incompatible plug-ins and assets

assets that relate to lit shaders or perform 

 modifications in the Built-in Render Pipeline are not typically compatible with URP or HDRP out of the box, unless noted by the author. Remove any incompatible plug-ins and assets from your Project.

 (or any shaders that are lit per pixel) do not work in URP or HDRP. They either render as pink, or not render at all.

You must replace these Materials with the equivalent shaders in the render pipeline you are using. The URP replacement for the Standard Shader is UniversalRP/Lit. The HDRP replacement for the Standard Shader is HDRP/Lit.

Alternatively, you can use the Render Pipeline Wizard to perform Material conversion:

Edit > Render Pipeline > Universal Render Pipeline > Upgrade Project Materials to UniversalRP Materials

Edit > Render Pipeline > Upgrade Project Materials to High Definition Materials

Some unlit shaders might work in URP or HDRP, but this is not guaranteed and might not be consistent across render pipelines. For example, the 

 Material is transferable to URP but not HDRP. To ensure forward compatibility, it is best to replace these shaders with their unlit equivalent for your new render pipeline.

and custom lit shaders in Shader Graph for them to work properly in URP or HDRP. For information on Shader Graph, see the 

The Built-in Render Pipeline works with the Post Processing Stack V2 package, and the now-deprecated Post Processing V1 solution. URP and HDRP contain their own integrated 

To prepare to convert your post-processing solution from Post Processing Stack V1 to URP or HDRP:

Remove the Post Processing Behaviour component from all 

To prepare to convert your post-processing solution from Post Processing Stack V2 to URP or HDRP:

Remove the Post-process Layer component from all Cameras.

Remove all Post-process Volume components, and delete the Profile Assets from the project.

To begin working with the integrated post-processing solution in URP or HDRP:

1. Create a new Global Volume, and assign a new Volume Profile to it.

2. Configure the Volume Profile by adding overrides for the desired post-processing effects.

: Select the Camera your application uses and make sure “Render Post Processing” is enabled. You can enable Anti-Aliasing for the in game camera without adding additional components. 

: You can enable different types of Anti-Aliasing in the 

unrelated to what you use on the game camera. 

Some post-processing effects are available in HDRP, but not URP. Some are in development while others are not suitable for the particular render pipeline. You should check which post-processing effects are available in the render pipeline that you are using, and determine how to recreate the visual effects in your project.

In Spotlight Tunnel, the most important post-processing effect is the Tonemapper. This effect works the same in URP and HDRP.

Key differences in post-processing between URP and HDRP that affect this update to the Spotlight Tunnel project:

Bloom works differently in URP and HDRP, and requires different settings. For more information, see the 

The Screen Space Reflections effect is not available in URP.

 was not available in URP at the time this update was created.

Support for lighting features varies considerably between render pipelines. For example, the Built-in Render Pipeline supports 

, but URP and HDRP do not. The different render pipelines also support different Lighting Modes for Mixed Lights; for example, HDRP does not support Subtractive Lighting Mode, and URP does not support 

Lighting Mode. For full details of which render pipeline supports which lighting features, see 

Before you convert your project to a different render pipeline, you should choose a lighting strategy that is compatible with your desired render pipeline and works well on your target hardware. The different lighting strategies in the URP and HDRP versions of Spotlight Tunnel demonstrate this.

The URP version of Spotlight Tunnel focuses on runtime performance:

The Main Directional Light (sun) has its 

 to cast real-time shadows while still producing bounce lighting. 

The HDRP version of Spotlight Tunnel focuses on high fidelity rendering:

Baked Global Illumination is enabled, with the CPU Progressive Lightmapper as a backend. 

 to preserve high quality specular lighting on stationary lights; Lights with their 

 are used wherever they are needed for consistent shadowing. 

Note that, depending on your hardware configuration, the GPU Progressive Lightmapper might result in faster 

baking than the CPU Progressive Lightmapper.

In addition to choosing an overall lighting strategy, you should be aware of the differences in Light types between different render pipelines.

Differences between the Built-in Render Pipeline and URP:

In the Built-in Render Pipeline, the distance fall-off for Spot and Point Lights doesn’t follow any physical laws. In URP, the distance fall-off for Spot and Point Lights follows the inverse square law. Generally speaking, Lights lose more intensity over distance in URP, and you need to amend your 

 value of Directional Lights from the Built-in Render Pipeline to URP, use the following formula: URP Directional Light Intensity = (Built-in Renderer Pipeline Directional Light Intensity)^2.2. For example, a value of 7.5 in the Built-in Render Pipeline is equivalent to a value of 84.17 in URP.

Differences between the Built-in Render Pipeline and HDRP:

HDRP uses a physically based lighting unit and fall-off for all Light types. You must completely recreate your lighting using physically based values.

HDRP supports additional Light types, such as Spotlight Pyramid/Box, Realtime Tube, and Realtime Rectangular lights. These can help you achieve different realistic effects.

Each render pipeline has slight differences in how they handle reflection capturing and reflection blending, and it is likely that you will have to change the position and distribution of the 

For comparison are the reflection systems used in the different versions of Spotlight Tunnel:

Built-in Render Pipeline: Reflection Probe (Deferred w/blending), ScreenSpace Reflection, Skybox.

HDRP: Reflection Probe w/blending. ScreenSpace Reflection, Skybox. In URP:

Converting from the Built-in Render Pipeline’s Deferred reflection to URP requires some manual work, as URP’s Forward Reflection Probe doesn’t blend. Converting from Built-in Render Pipeline’s Deferred reflection to HDRP reflection is straight forward as they both have equivalent blending methods.

Converting your project between URP and HDRP

Conversion from HDRP to URP and vice versa is possible, but it is not automatic and the manual process may be difficult. How difficult the process is mainly depends on how complex your project’s shaders are; if your project mostly uses the render pipeline’s built-in shaders, the process is much easier.

Spotlight Tunnel project was successfully converted from HDRP to URP, with these caveats:

There is no wizard to assist with Material conversion, but you can select multiple Materials and switch them to the new render pipeline shader. Most of the Materials in Spotlight Tunnel HDRP are HDRP Lit with basic Texture packing, and in most cases they translated to URP Lit without problems. Note that not all texture assignments can transfer directly, because there are many shader features that are different between URP and HDRP; double check each material to make sure texture assignments are properly set.

Post-processing profiles and settings are different between URP and HDRP. Post-processing effects needed to be manually recreated.

Some Light types from HDRP are not available in URP.

The Lighting Unit in URP is different to that in HDRP. Lighting effects needed to be manually recreated.

The Skybox Material is not compatible between URP and HDRP. We replaced the HDRP Skybox Material with one suitable for URP.

Believable visuals in URP and HDRP

Note that this guide was originally created for use with the Built-in Render Pipeline in Unity 2017.3. For information on adapting this guide for use with the Universal Render Pipeline (URP) and the High Definition Render Pipeline (HDRP), see 

Update: believable visuals in URP and HDRP

The first step is to get your Assets into a format suitable for what you want to do. It’s very important to set up a proper workflow from your 3D modeling application, such as Autodesk® 3ds Max®, Autodesk® Maya®, Blender, and Houdini, into Unity. When 

exporting assets from 3D modeling applications for import into Unity

Your project scale, and your preferred unit of measurement, play a very important role in a believable 

. In many “real world” setups, we recommend you assume 1 

 = 1 meter (100cm), because many physics systems assume this unit size. For more advice, see the 

To maintain consistency between your 3D modeling application and Unity, always validate the imported GameObject scale and size. 3D modeling applications have units and scale settings in the FBX export configuration (see the documentation for your 3D modelling software for configuration advice). Generally, the best way to match the scale when importing to Unity is to set these tools to work in centimeters, and export FBX at automatic scale. However, you should always check that the unit and scale settings match when starting a new project.

To quickly validate your export settings, In your 3D modeling application, create a simple 1x1x1m cube and import it into Unity. In Unity, create a default Cube (

). This is 1x1x1m. Use this as a scale reference to compare with your imported model. These cubes should look identical when the 

Maya and 3DsMax can override your default unit depending on the last opened file.

Be aware that 3D Software can display different unit in the workspace while having different settings in their "internal unit". This might cause some confusion.

When blocking out a Scene with placeholders or sketching geometry, having a point of reference scale model can be helpful. Choose a point of reference scale model that is appropriate for the Scene you’re making. In the Spotlight Tunnel Sample Scene case, we use a park bench: 

Your Scene doesn’t have to use exactly the same proportions as real life. Using a point of reference scale model simply allows consistencies of scale to be relative between GameObjects, even if the Scene is intended to have exaggerated proportions. 

The information inside a texture needs to contain the correct information to give a proper result when added to a Material. Texture authoring software, such as Photoshop and Substance Painter, outputs consistent and predictable textures when you configure them correctly.

Here’s an example of a pre-set configuration for Substance Painter to output textures for use with a Unity Standard Opaque material:

The texture assignment in the Unity Standard Material is: 

$textureSet_Albedo: assigned to Albedo Slot.

$textureSet_MetallicAOGloss: assigned to Metallic and Occlusion, smoothness Source set to Metallic Alpha.

$textureSet_Normal: assigned to Normal Map Slot.

: Packing multiple channels to a single texture, such as the MetallicAOGloss, saves texture memory compared to exporting 

 (AO) as a separate texture. This is the best way of working with a Unity Standard Material.

When creating textures, it’s important not to mix up the alpha channel. The example below shows how transparency in a PNG file can be confusing to author in Photoshop because of the way Photoshop deals with a PNG alpha channel (without using an external plugin). In this case, an uncompressed 32-bit TGA with a dedicated alpha channel might be a better option, assuming the source texture file size is not an issue:

The transparent PNG file shown above was created in Photoshop with its alpha channel coming through as a black value. The TGA with a dedicated alpha channel shows the expected value. As you can see above, when each texture assigned to the 

material reads smoothness data from the alpha channel, the smoothness of the material with PNG textures is unexpectedly inverted, while the smoothness of the material with TGA textures is normal. 

 Unity reads tangent space normal maps with the following interpretation:

 normal map outputs the Green Channel Y+ as 

 by default. This causes an inverted surface direction along the Y axis and creates invalid results when lit. To validate the normal map direction, create a simple plane with concave bevel (middle picture on the example below) and bake it to a flat plane. Then assign the baked normal map into a plane in Unity with identifiable light direction and see if any of the axes are inverted.

For advice on axis settings, refer to your 3D modelling application’s documentation. 

Preparing Assets for Unity

The following advice helps you understand how to use Unity’s rendering features to realistically mimic the real world, and quickly achieve your project’s believable visual goal.

For more in-depth information, see Unity’s 

In simple terms, the linear rendering mode prepares Unity to do lighting and shading calculations using physically accurate mathematics before transforming the final output into the format that works best for monitors.

Defining your color space should be one of the earliest decisions in your project because of the drastic impact on the final shading and lighting results. For more advice on each workflow, see 

Work with multiple dynamic lights efficiently

Use the existing Screen Space Reflection features in Unity 2017+

To set the rendering path in the Editor, select 

 category. Alternatively, you can select the 

For more information on the rendering mode, see 

 lighting properly, follow these steps to set it up and enable tonemapping:

 (Academy Color Encoding Standards). For advice on using ACES tonemapping to handle high intensity color values, such as colored light or fire, see 

. Dithering allows the Scene to alleviate banding artifacts introduced by 8 Bit/channel output from an HDR Scene. Modern engines use this technique to circumvent the limitation of 16M color output.

The Spotlight Tunnel sample scene uses the post-processing stack V1. For advice on using post-processing stack V2, refer to the 

When rendering believable lighting, you’re dealing with lighting values and emissive surfaces that have a brightness higher than 1 (high dynamic range), much like real life. You then need to remap these values to the proper screen range (see 

). The high dynamic range setting is crucial because it allows the Unity 

 to process high values, rather than clip them. To enable HDR, select the 

The Spotlight Tunnel Sample Scene doesn’t use baked lighting. However, if you’re planning to use HDR baked lighting, set the light map encoding to HDR light map for consistent results.

To set lightmap encoding in Unity, go to 

To see the tonemapper while working with the Scene, enable 

. In the following image, notice the highlight rendition and the dark tunnel value separation improvements in the tonemapped Scene. If you look at the non-tonemapped Scene, you can see how the highlights didn’t converge to a unified color (the yellowish burning sun in this case).

This setup essentially tries to replicate how a digital camera captures a Scene with a fixed exposure (without exposure adaptation/eye adaptation features enabled).

At this point, you have a proper foundational Scene rendering setup that should give believable results with a wide range of content:

Preparing render settings in Unity

Before starting to create final assets and approaching lighting for a Scene, it is important to figure out your lighting strategy. At the start of a project, it is very easy for content creators - eager to start making cool things - to overlook this important step. Altering your lighting strategy late in development is a costly operation. Taking the time to get this right before you enter production will save time while giving better performance and a higher visual fidelity.

Much like anything in real life, there’s almost always trade-off between the benefits and costs of one setup or another. Just as a Formula 1 Car isn’t well suited for everyday grocery shopping compared to its gas saving hybrid car siblings. There are times, however, where certain technologies will give you options to mitigate these trade-offs within specific constraints and knowing each features and trade-off will allow you to choose what’s best for your project.

A typical daytime Scene with outdoor areas has the following lighting components: 

This seems like three simple components. But because you can mix and match 

, you can end up with a diverse range of lighting options. 

Unity caters to lots of different lighting strategies and project scenarios. To understand lighting modes and setup, see documentation on 

For newcomers, it can be overwhelming to figure out which setup works best for their Scene, and what the trade-offs are. So let’s consider the most commonly used lighting setups:

: The specular highlights from the light are visible, but there is no indirect lighting.

: Soft baked shadows are visible, and static indirect lighting is visible in high resolution, but there are no specular highlights from lights, and dynamically lit GameObjects don’t cast shadows.

 lighting, but there is specular response from lights, and dynamically lit GameObjects do cast shadows.

: Proper indirect lighting response and specular response are visible, lights are all moveable and updateable, but there’s no angular soft shadow.

: Depending on the settings of each light, you can achieve the combination of all the above options.

The following images show the notable differences between these setups:

Here are the general characteristics for each configuration:

Basic Realtime lighting and Ambient (with no Realtime GI or Baked GI)

Basic real-time lighting is generally used in stylistic visual projects and prototype phases. 

All direct lights and shadows are applied in real time, and are therefore movable.

Allows for fast iteration, because there is no precomputation, baking, or 

Dynamic and Static GameObjects are lit using the same method, so 

/ambient value, and the color in the area is not lit by direct lighting.

Without GI or indirect lighting component, the Scene might not give the best visual outcome.

Baked lighting is generally useful for games where run-time performance is an issue but there’s room in memory, such as top-down isometric mobile games and high frame-rate VR games. 

Mobile platform, VR, console and low end PC

All lights are baked for static GameObjects. They produce ambient occlusion and indirect lighting.

Unity can bake area light bake support and soft shadow angles onto statically lit GameObjects.

Fastest run-time performance among the common setups listed here.

Can slow down lighting iteration because lights are baked, which means Unity needs to re-compute lights whenever the Scene changes (unless you’re using Progressive Lightmapper).

Dynamically lit GameObjects are only lit using Light Probes.

There is no shadowing from dynamic GameObjects.

Can require a lot of run-time memory, depending on how many light map textures are used in the Scene.

Might require authoring texture coordinates channel 2 (UV2 for light map) if GameObjects texture charts overlap.

Mixed lighting with Shadowmask and Light Probe

Mixed lighting is often useful in games where time-of-day lighting (such as sun movement) is not important. 

Similar to all Baked lighting, but in Mixed lighting, Dynamic GameObjects get real-time specular lighting and cast real-time shadows, while static GameObjects get baked shadowmasking, resulting in better visual quality.

GameObjects have a limit of 4 Shadowmasks. Additional shadow casting lights gets baked.

real-time lights at run time is more resource-intensive.

Mixed lights can drastically affect performance in certain setups.

For more information on Shadowmask lighting, see 

Realtime lighting with Realtime GI and Light Probe

This setup is useful in open area games where you need time-of-day lighting updates (such as the sun moving) and dynamic lighting effects. 

This allows for fast lighting iteration with real-time indirect lighting.

Dynamic and static GameObjects get real-time specular lighting and shadows.

Can use less memory than Baked lighting for indirect lighting.

Has a fixed CPU performance impact for updating 

Occlusion isn’t as detailed as Baked lighting, and usually must be augmented by Screen Space Ambient Occlusion (SSAO) and per-object texture baked AO.

No area/light angle soft shadows for static GameObjects.

Real-time lights can drastically affect performance in certain setups.

Precompute times can take a significant amount of time if there are too many GameObjects contributing to the static lighting, especially without an optimized UV setup. For more information, see 

You would only want to generally enable all lighting options in games with high fidelity requirements that have tightly controlled memory usage and performance limits. You should only do this if you fully understand each individual system, and know how to handle each lighting combination. 

This is the complete set of lighting features, giving you full functionality.

Has high performance requirements at run time, with high memory usage.

Increases the workflow time, by requiring more UV authoring and baking time.

To help you learn about lighting, the Spotlight Tunnel Sample Scene uses real-time lighting with Realtime GI. This provides a diverse range of specular responses, good bounce lighting, and allows you to quickly iterate on lighting.

Lighting strategy

One of the mistakes that content creators usually make is not planning for what’s ahead before modelling. It’s ok to do fast and loose modelling during pre production or for roughing out a space, but the moment there’s a need for the asset to be somewhat finalized, there are a few things that need to be thought out ahead of time. Here are few things to keep in mind when modeling a proper Scene that might be overlooked even by seasoned content creators.

Despite modern hardware being more capable than ever, simple geometry is always beneficial in a Scene. Unnecessary tessellation and complex geometry is difficult to manage for a real-time setup, and it can impact performance and use memory unnecessarily. The following example demonstrates how geometry that is never seen by the players wastes resources such as 

If you are using Baked lighting or Realtime GI with 

contributes to lighting in a Scene, or only receives indirect/baked lighting in the Scene.

To set a GameObject to contribute to lighting, make sure 

window. This provides simpler and smoother surface areas that produce better indirect bounces/baked lighting because of their efficiency in space usage for lightmap textures. Note that:

You might need to author UV2 for the geometry when doing a light bake, if the auto lightmap UV provides inefficient chart or generate undesirable seams.

You might need to author UV3 for the geometry for efficient results in Realtime GI.

Sometimes, in Realtime GI, you can simplify a UV of a 

to make the geometry use significantly less resources, and produce the best result with fewer artifacts.

GameObjects that only receive lighting in the scene

When GameObjects only receive lighting from real-time lights and Light Probes, the geometry doesn’t have a lightmap UV restriction. The geometry still needs special attention if it’s large, because it might not be lit properly with a single Light Probe, and might require a 

 to stitch together multiple probe light definitions.

You don’t always need to use a lightmap or use Realtime GI for non-moving GameObjects. If a GameObject is small, or it doesn’t have surfaces that bounce much light, it probably doesn’t need to be included in the lightmap. The bench and railings shown below are a good example:

The UV layout can help improve visual quality while using the same amount of memory for 

Unity Version 2019.4