Game Scene Lighting Setup and Optimization

Lighting that looks great in the editor often breaks on target platforms. We are certified Unity and Unreal Engine specialists. We configure game scene lighting turnkey, working with URP/HDRP, ensuring consistency from editor to target platforms. Over 5 years, we’ve implemented lighting schemes for 20+ projects — from mobile casuals to PC horrors. We guarantee results that pass Frame Debugger and RenderDoc without surprises.

Why Lighting Breaks on Mobile Platforms

In URP projects, a standard mistake is mixing Forward and Deferred Rendering Paths without accounting for the fact that Deferred does not support MSAA and works differently with Normal Maps on some platforms. Some light sources start behaving unpredictably, especially Point Lights with low Intensity but large Range — they hit the per-object light limit (default 8 additional lights in Forward), and on mobile platforms this limit is stricter.

A second classic failure: lighting looks fine in the scene, but after Lightmap baking, all shadows are offset. This happens due to incorrect Shadow Bias on the Source Light — when Directional Light has Normal Bias above 0.4, static shadows from baking do not match dynamic shadows in Mixed mode. The result is a "double shadow" at the junction of baked and real-time lighting.

How to Properly Configure Color Temperature

Engineers often set the light color directly via the Color picker. The correct approach is to use Color Temperature (Kelvin). 2700K gives a warm evening incandescent light, 5600K neutral daylight, 8000K a cold blue tint of an overcast sky. When changing time of day via Timeline or Shader, simply animate the Kelvin value, and the whole scene changes tone organically without manually tweaking each source.

In URP, Color Temperature is enabled via Additional Light Data → Use Color Temperature. In HDRP it is a standard parameter of HD Additional Light Data.

Lighting Architecture: From Large to Small

Start with the key light source — Sun/Moon for outdoor scenes, main ceiling light or window for interiors. A Directional Light with correctly set Color Temperature and Intensity sets the tone for the whole scene. In HDRP, this is easier using Physically Based Sky + HDRI Sky to get correct ambient.

Next is the back/rim light for character readability against the background. A separate Source Light with low Intensity aimed opposite the main light prevents the character from blending into the background even in dark areas. In most projects, this light is made invisible to the environment via Light Layers (HDRP) or Culling Mask.

Accent lighting — Point Lights and Spot Lights — creates visual interest in the frame, highlights interactive objects, and adds atmospheric effects. Here it is important to control the count: each additional source in Forward Rendering adds a pass for each illuminated object. On mobile devices, 4 additional lights are already many.

Comparison of Forward and Deferred Rendering for Lighting

From Our Practice: Horror Game with Overly Bright Dark Areas

On a horror project, the client complained that dark corridors looked "soapy" — soft shadows, no contrast. The problem was the Ambient Light: it was set via Environment Lighting → Source: Color with Intensity 0.8 — effectively a Fill Light for the whole scene. After switching to Source: Gradient with Sky Intensity 0.05, Ground Intensity 0.02, and removing Equator, dark areas became truly dark, and Light Probes began correctly conveying the difference between lit and unlit areas to the character.

Lighting and LOD: A Problem Noticed Too Late

When using LOD Groups, there is a nuance that regularly surfaces mid-project: lights with Culling Mask and Light Layers behave differently on different LOD levels only if the Renderers on those levels have different Layer settings. But more often the problem is different — on LOD2 and LOD3 there are often simplified Meshes without Normal Maps, but the shader is the same as on LOD0. As a result, when LOD switches, lighting changes abruptly: the normal model looks glossy, while the simplified LOD appears flat.

The correct approach: for LOD2+ use simplified shaders (Lit → Simple Lit or Custom Unlit with baked AO) instead of the full PBR stack. This is not only visually more correct but also reduces GPU load when rendering distant objects.

Another point with Emissive materials in Baked GI: an object with Emissive can "bake" its glow into surrounding lightmaps only if it has Contribute GI enabled and the Emission parameter in the shader is wired to Lightmap Emissive. In URP/Lit, this is Emission → Baked Emission. If this flag is not enabled, the object glows by itself but does not light anything in the baked lightmap — a common reason why a "glowing" screen or window does not cast light on the floor around it.

Tools for Lighting Diagnostics

Frame Debugger (Window → Analysis → Frame Debugger) allows stepping through each draw call to see which Pass handles a specific object. Indispensable for understanding why an object is lit unexpectedly.

Rendering Debugger in Lighting mode (Albedo / Specular / Normal / Direct Diffuse) breaks down lighting into components. If a Normal map doesn't affect lighting as expected, it shows immediately in Normal view.

GPU Usage Profiler shows how much GPU time is spent on Shadow Caster Pass for each light. If one Spot Light with Shadow Casting on takes 3ms, it's a reason to either reduce Shadow Resolution for that light or switch it to non-shadow mode and simulate the shadow with a Blob Shadow texture.

For HDRP projects, there is a dedicated tool — Light Explorer (Window → Rendering → Light Explorer). It displays all lights in the scene as a table with modes, intensity, and shadow type. Handy for auditing scenes with over 20 lights; no need to click each one in the Hierarchy.

What Our Work Includes

• Audit of current lighting and render pipeline
• Setup of key, fill, and back light based on the artistic brief
• Optimization for target platforms (including mobile, console)
• Baking of Lightmaps and Light Probes
• Documentation of the lighting scheme and recommendations for the team
• Support for two weeks after delivery

Process and Timelines

Work begins with an artistic brief: references, time of day, atmosphere, target platform. Then technical scene audit (number of lights, current Render Path, engine version). This is followed by base lighting setup with iterative approval. Final stage: optimization and testing on target devices.

Pricing is calculated individually after analyzing the requirements and current state of the project. Get a consultation on your project — contact us.

What problems does lighting setup solve?

A studio spends four hours per bake per scene. A UV seam artifact appears, the artist fixes it, and waits another four hours. This repeats three to five times daily across multiple scenes, wasting weeks. An incorrect lighting strategy from the start — all sources in Realtime — can cost 30–50% FPS on mobile or consoles at release. Our Expert Lighting and Rendering Setup Services address two core pain points: baking time and runtime performance. We audit the existing system, choose the right mix of dynamic lighting and baked methods, and deliver measurable gains. Over 30 projects delivered, from indie to AA. Certified Unity specialists guarantee the result.

Dynamic, static, and mixed lighting: how to choose?

Each light source in Unity has three modes. The table shows how they affect performance:

A common mistake: a studio sets all lights to Realtime, resulting in 12 shadow-casting lights on screen. On mobile, that’s a guaranteed 30% FPS drop. Mixed Lighting with Subtractive or Shadowmask sub-modes is the practical compromise. Static objects get baked shadows, dynamic objects get realtime shadows from same sources — a balanced dynamic lighting mix.

Typical artifacts and their causes

How to optimize baked lighting without losing quality?

Choosing between Enlighten and Progressive Lightmapper

Unity supports two baking backends. Enlighten is legacy real‑time GI — officially outdated but still used on mobile due to low system requirements. Progressive Lightmapper (GPU) is a modern path‑tracing backend. On an NVIDIA RTX card, GPU baking is 5–10x faster than CPU. We default to Progressive Lightmapper (GPU) for PC and consoles.

Key parameters for a typical scene:

Lightmap Resolution:    10–20 texels/unit
Max Bounces:            2–4 (not default 8)
Samples (Direct):       32–64
Samples (Indirect):     512–1024
Denoiser:               OIDN or OptiX

Denoiser is mandatory. Without it, you need thousands of samples for clean results. With denoiser, 256–512 samples suffice. Iteration takes minutes, not hours. According to Unity documentation, this setup reduces baking time by 50–70% without quality loss.

Light Probes and Reflection Probes: why and how to set up?

Light Probes give dynamic objects the illusion of baked lighting. Place probes every 2–4 meters in areas with lighting variation. Too sparse placement causes sharp jumps when characters move. Probe Volumes (HDRP) replace manual placement with a volumetric grid — saves time on large open scenes.

Reflection Probes correct reflections on PBR materials. Without them, metal and mirrors reflect the skybox instead of the environment. Settings:

• Baked for static rooms
• Realtime for zones with changing environment (TV, screens)
• Box Projection for correct room geometry reflection

Applying these rules reduces draw calls for reflections by up to 40%.

What is the impact of scene organization on baking speed?

Scene scale is the main enemy of fast baking. Here’s the process we use:

1. Exclude objects smaller than 0.5 units — they receive lighting via Light Probes.
2. Use Instanced Meshes for repetitive objects (trees, rocks, fences) — one UV atlas shared.
3. Bake Terrain separately at reduced resolution (2–5 texels/unit).
4. Check Backface Tolerance on complex geometry — prevents dark spots.

Following these steps cuts total bake time by 50–70%. In one open‑world Unity project, original bake time was 4 hours per scene. After optimization: 1 hour 20 minutes. Monthly time savings exceeded 40 hours, equivalent to $3,000 monthly cost reduction.

What’s included in lighting setup work

Our turnkey service delivers:

1. Audit of current system — profiling via Frame Debugger and RenderDoc, identifying bottlenecks.
2. Lighting strategy — documentation with mode selection (Mixed/Baked/Realtime) for your platform.
3. Baking optimization — UV unwrapping, Progressive Lightmapper configuration, Light Probes.
4. Reflection Probes setup and post‑processing (SSAO, SSR, Bloom) matching your artistic style.
5. Final report with performance metrics (FPS budget, draw calls, frame times).
6. Post‑delivery support for two weeks — remote session to review any issues and transfer knowledge.

Work process and timeline

We follow a clear workflow:

• Analysis (1–2 days) — review scene, take screenshots, profile.
• Design (1 day) — select strategy, create optimization plan.
• Implementation (3–7 days depending on complexity) — UV fixes, Lightmapper settings, Light Probes, post‑processing.
• Testing (1–2 days) — measure performance, remove artifacts.
• Delivery — scene files, documentation, checklist.

Typical timeframe: 5 to 15 business days. Pricing is individual — contact us for a project estimate.

Get a free audit of your current lighting setup. Reach out to discuss your project — we will provide a concrete plan and timeline.