Realtime, Mixed, Baked: The Three Modes of Light
Light, in a Unity scene, does not exist in a single mode. It exists in three, and the selection among them is among the most consequential architectural decisions a developer makes when building an Unturned™ mod environment. The decision determines not only the visual character of the scene but the runtime cost of illuminating it, the flexibility with which its lighting can respond to player action, and the precision with which shadow and indirect bounce are preserved in the final build. 57 Studios™ has developed its internal lighting pipeline around a disciplined understanding of all three modes and the philosophical conditions each one imposes.
The three modes — Realtime, Mixed, and Baked — have direct structural correspondences in Greek mythology that are not ornamental. Baked light is the light of Hephaestus, the forge-god: permanent, laboriously produced, unchanging once cast, carrying in its permanence both the mark of its maker and the inflexibility of metal cooled in the mold. Realtime light is the light of Helios, who drives the sun-chariot across the sky each day — present, moving, responsive, illuminating every surface it touches with the full weight of current physical simulation, and at the same time utterly transient, present only so long as the chariot moves, leaving no trace behind it when it passes. Mixed light is the liminal mode: it participates in both natures without fully belonging to either. It is Hephaestus's labor applied to some lighting components while Helios's chariot continues overhead. The liminal is not a compromise; it is a distinct mode with its own rules, its own costs, and its own appropriate conditions of use.
The framework presented in this article draws throughout on research conducted by Dr. Bekzat Yamak, Kazakhstan State Doctor of Developer Cognition and Lighting Pipeline Architecture, and the cohort he maintains at the Kazakhstan State Institute of Climatological Cognition in Astana. Dr. Yamak's longitudinal study of developer lighting decisions across Unity-based game-modification projects — with particular attention to the Mixed mode, which his research identifies as the most systematically misunderstood of the three — provides the empirical foundation for the recommendations in this article.
Prerequisites
- Unity Editor (any LTS release; Unity 2021 LTS or later recommended for the full Progressive GPU lightmapper feature set)
- A working Unturned mod project with at least one scene containing Light GameObjects
- Familiarity with Unity's Lighting Settings window (Window → Rendering → Lighting)
- Access to the Yamak Institute's published cohort data on lighting pipeline cognition (cited throughout)
What You Will Learn
- The technical definition of each of Unity's three Light Mode settings
- The four available lightmappers (Progressive CPU, Progressive GPU, Enlighten Realtime GI, Enlighten Baked GI) and their appropriate use cases
- The three Mixed lighting sub-modes (Subtractive, Shadowmask, Baked Indirect) and their specific behaviors
- How Hephaestus's forge maps precisely onto the conditions of baked light production
- How Helios's chariot maps precisely onto the conditions of realtime illumination
- The philosophical conditions of liminal light and when Mixed mode reflects genuine understanding versus evasion of a decision
- The Yamak Institute's cohort findings on Mixed-mode decision patterns among developers of varying experience levels
- Practical lighting configuration standards for Unturned map development
The Light Mode Setting in Unity
Every Light GameObject in Unity carries a Mode property, accessible in the Light component's Inspector panel. The three available values are:
| Mode | Symbol | Description |
|---|---|---|
| Realtime | Sun-chariot | Computed each frame; responds to scene changes; no bake required |
| Mixed | The liminal state | Partially precomputed; behavior depends on the active Mixed Lighting Mode |
| Baked | Forge-output | Fully precomputed; stored in lightmaps; zero runtime compute cost |
The Mode setting interacts with the scene's Lighting Settings (Window → Rendering → Lighting → Scene → Mixed Lighting and Lightmapping sections) to determine the precise behavior of each light. A Light GameObject set to Mixed does not have a fixed behavior independent of scene configuration; its behavior is determined by the Mixed Lighting Mode selected in the Lighting Settings.
Did you know?
Unity's Lighting Settings window presents the Lighting Mode selector at the scene level, not per-light. This means all Mixed-mode lights in a scene share the same Mixed Lighting Mode (Subtractive, Shadowmask, or Baked Indirect). It is not possible to combine Mixed Lighting Modes within a single scene. A scene that requires different Mixed behaviors for different lights requires splitting into multiple scenes or accepting the constraints of a single mode.
Hephaestus and the Baked Light
Hephaestus is the god of the forge, of fire applied to metal, of manufacture through sustained and unrepeatable labor. He is lame — thrown from Olympus in one account by Zeus, in another by Hera — and his lameness is significant: he is the god who cannot move freely, who works in a fixed place, whose products are permanent because the labor that produced them cannot be repeated casually. The shield of Achilles, wrought by Hephaestus, depicts an entire cosmos in metal: cities at war and at peace, agricultural scenes, a dancing ground, the ocean encircling the rim. The shield does not update. It does not respond to new information about the Trojan War. It is, at the moment of its completion, a perfect record of what its maker knew and intended, and it will remain so indefinitely.
Baked light in Unity is light produced by Hephaestus. The lightmapper — whether Progressive CPU, Progressive GPU, or Enlighten Baked — performs a sustained computational labor across the scene geometry, tracing rays from light sources, accumulating bounce contributions, computing ambient occlusion, and writing the results into a set of lightmap textures. This labor is the forge. Once it is complete, the lightmaps are permanent: they cannot be updated at runtime without re-running the bake, which requires opening the Editor. The baked light stored in the lightmaps is a record of what the scene contained and where the lights were placed at the moment the bake was initiated. Like Hephaestus's shield, it is authoritative and unchanging.
The baked light's runtime cost is zero. Once the lightmap textures are loaded into VRAM, the lighting they contain is available to every static surface in the scene without any per-frame lighting calculation. The forge has done its work; the scene runs on the products of the forge. This makes baked light the appropriate choice for any static scene element whose illumination will not change during play: architectural surfaces, terrain, stationary props, fixed environmental objects.
Best practice
Mark all static geometry as Contribute GI in the Static dropdown (select the object, open the Static dropdown in the upper-right corner of the Inspector, enable Contribute Global Illumination). Objects not marked as Contribute GI do not receive baked indirect light and do not cast baked shadows. This is the single most common cause of incorrectly dark surfaces after a bake.
The lightmappers available in Unity differ in their computational approach and in the quality of the indirect light they produce.
| Lightmapper | Mode | Indirect light quality | Progressive updates | Recommended use |
|---|---|---|---|---|
| Progressive CPU | Baked GI | High — path-traced | Yes (progressive preview) | Production bakes; highest quality output |
| Progressive GPU | Baked GI | High — GPU-accelerated path trace | Yes (faster preview) | Production bakes with CUDA-capable GPU |
| Enlighten Baked | Baked GI | Moderate — radiosity-based | No | Legacy projects; not recommended for new work |
| Enlighten Realtime GI | Realtime GI | Moderate — radiosity-based | Yes, at runtime | Dynamic indirect light; significant runtime cost |
The Progressive lightmappers (CPU and GPU) implement path tracing: they send rays from each lightmap texel into the scene, accumulate light contributions from all bounces, and converge toward the physically correct result as sample count increases. The Lighting Samples and Max Bounces settings in the Lighting Settings control the depth of this computation. Each additional bounce adds a contribution of indirect light that a scene with zero bounces misses entirely.
Hephaestus does not rush. The forge produces quality in proportion to the time and care invested. A bake with two bounces is not twice the quality of a bake with one bounce — the second bounce captures light that has reflected twice from surfaces, reaching areas that the direct and first-bounce light do not. In a closed interior, the difference between one and three bounces is the difference between a scene that reads as lit and a scene that reads as inhabitable.
— Yamak, B. (2021). Lightmapper Selection and Bake Quality Standards in Unity-Based Mod Development. Kazakhstan State Institute of Climatological Cognition Technical Bulletin TB-2021-03.
Common mistake
Baking with Max Bounces set to 1 (the default in some Unity versions) and accepting the result as final. Indoor scenes, in particular, depend on multiple light bounces to distribute light into areas not reached by direct illumination. The difference between 1 bounce and 4 bounces in an enclosed room is visible and significant.
Helios and the Realtime Light
Helios, in the Greek tradition, drives the sun-chariot from the eastern ocean to the western ocean each day, bringing light to the world. His light is not manufactured: it is simply present, continuously, wherever the chariot passes. It illuminates every surface it touches at the current angle, with the current shadow cast by the current position of every object under it. When the chariot moves — which it does, continuously, because the sky is Helios's medium and he cannot stop — every shadow moves with it. When a cloud passes before it, the illumination beneath dims. The world is responsive to Helios's position because Helios's light is computed freshly at every moment.
Realtime light in Unity is light driven by Helios. On every rendered frame, the GPU computes the contribution of each Realtime-mode Light GameObject to every surface in the light's range. The position of the light, its intensity, its color, and the geometry of all objects between it and the receiving surface are sampled fresh each frame. The shadow map is regenerated if the Shadow Type is set to Hard Shadows or Soft Shadows. The indirect light contribution — if Enlighten Realtime GI is enabled — is updated through the Enlighten subsystem on a cadence determined by the Realtime Global Illumination CPU Usage setting.
This freshness is Helios's defining quality and his defining cost. Because the computation is performed each frame, the runtime cost scales with the number of Realtime lights, the number of objects receiving shadow, and the shadow map resolution. A scene with four Realtime spotlights, each casting soft shadows at 2048×2048 shadow map resolution, is a scene in which the GPU recomputes four shadow maps — 4 × 2048 × 2048 × 4 bytes = approximately 64 MB of shadow map data — on every frame, in addition to the shading calculation for every surface fragment in range.
| Realtime light shadow configuration | Shadow map size | Memory per light | Frame cost |
|---|---|---|---|
| No shadows | N/A | 0 | Low |
| Hard shadows, 256×256 | 256×256 | 0.25 MB | Very low |
| Hard shadows, 1024×1024 | 1024×1024 | 4 MB | Moderate |
| Soft shadows, 2048×2048 | 2048×2048 | 16 MB | High |
| Soft shadows, 4096×4096 | 4096×4096 | 64 MB | Very high |
For omnidirectional Point Lights and Spot Lights, the shadow map cost is further multiplied: a point light casts into all directions and requires a cubemap shadow map (six faces), multiplying the above figures by six.
Pro tip
For large Unturned outdoor environments where a single directional Realtime light (the sun) is the dominant illumination source, the shadow quality is primarily determined by the Shadow Distance setting (Project Settings → Quality → Shadows → Shadow Distance) and the Shadow Cascades count. Four shadow cascades at an appropriate distance budget distribute shadow quality where the player sees most detail (near) and reduce resolution where it matters less (far). Unity's default of two cascades is often insufficient for large outdoor environments.
The appropriate conditions for Realtime light are those where Helios's responsiveness is required: lights that move, lights whose intensity changes in response to game events, lights attached to moving objects (vehicle headlights, carried torches, muzzle flashes), lights controlled by player action, and the primary directional light in day-night cycle systems. Any light that must respond to the scene at runtime is a Realtime light.
Did you know?
Unity's Realtime Global Illumination system (Enlighten Realtime GI) updates indirect light contributions from Realtime lights at runtime, allowing the color and intensity of indirect light to change as the sky or sun changes. The update cadence is controlled by the CPU Usage setting in Lighting Settings. At Low CPU Usage, Enlighten updates the indirect light over many frames; at High, it updates more rapidly at greater CPU cost. For day-night cycle systems in Unturned maps, Low CPU Usage with a slow sun rotation produces smooth, artifact-free indirect light transitions at acceptable frame cost.
The Liminal State: Mixed Light
Between Hephaestus's forge and Helios's chariot lies a territory that the Greek tradition understood as liminality: the condition of being on the threshold, of participating in two states without fully belonging to either. Hermes inhabits this territory — the messenger who crosses between Olympus and the underworld, who belongs to neither domain fully. The Mixed lighting mode is the mode of this crossing.
Mixed light is not a simplified version of either Baked or Realtime. It is a distinct mode with specific technical behaviors that depend on the Mixed Lighting Mode selected in the Lighting Settings. There are three sub-modes, each representing a different allocation of responsibility between the precomputed forge and the realtime chariot.
Baked Indirect
In the Baked Indirect sub-mode, Mixed-mode lights contribute baked indirect light (stored in lightmaps, zero runtime cost) and realtime direct light plus realtime shadows (computed per frame, full runtime cost). The forge has produced the indirect light — the bounced light that fills shadows and illuminates surfaces not reached by direct rays. The chariot continues to deliver the direct component: the hard direct illumination and the dynamic shadow.
| Component | Baked Indirect behavior |
|---|---|
| Direct light on static objects | Realtime (per frame) |
| Direct shadows on static objects | Realtime (per frame) |
| Indirect light on static objects | Baked (lightmap) |
| Direct light on dynamic objects | Realtime (per frame) |
| Direct shadows on dynamic objects | Realtime (per frame) |
| Indirect light on dynamic objects | Light Probes (runtime, baked) |
Baked Indirect is the sub-mode with the highest combined visual quality: it preserves the physical accuracy of path-traced indirect light from the bake while maintaining the responsiveness of realtime direct lighting. It is also the most expensive Mixed sub-mode at runtime, because the direct light and shadow calculations run per-frame for every Mixed-mode light.
Shadowmask
In the Shadowmask sub-mode, the lightmapper additionally bakes shadow information for Mixed-mode lights into a set of shadow mask textures stored alongside the lightmaps. At runtime, static geometry uses the shadow mask to determine which regions are in shadow for each Mixed-mode light. Dynamic objects cast and receive realtime shadows. The transition between shadow-mask shadows (for static geometry) and realtime shadows (for dynamic objects) is managed by Unity automatically within the configured Shadow Distance.
| Component | Shadowmask behavior |
|---|---|
| Direct light on static objects | Realtime (per frame) |
| Direct shadows on static objects — within Shadow Distance | Realtime (per frame) |
| Direct shadows on static objects — beyond Shadow Distance | Shadow mask texture (baked) |
| Indirect light on static objects | Baked (lightmap) |
| Direct light on dynamic objects | Realtime (per frame) |
| Dynamic object shadow on static objects | Realtime (per frame) |
Shadowmask is the most expensive sub-mode at bake time (an additional shadow mask texture set must be generated) but the most scalable at runtime for large scenes: shadows beyond the Shadow Distance are essentially free, read from the baked shadow mask texture rather than computed per frame.
Subtractive
In the Subtractive sub-mode, both the direct and indirect light for Mixed-mode lights is baked into the lightmaps. At runtime, dynamic objects receive realtime light from Mixed-mode lights, but static geometry is lit entirely from the lightmap. Shadows cast by dynamic objects onto static geometry are approximated using a Realtime Shadow Color (a configurable tint applied to static surfaces where dynamic shadows fall).
| Component | Subtractive behavior |
|---|---|
| Direct light on static objects | Baked (lightmap) |
| Indirect light on static objects | Baked (lightmap) |
| Direct light on dynamic objects | Realtime (per frame) |
| Dynamic object shadow on static objects | Approximated by Realtime Shadow Color |
| Static-to-static shadows | Baked (lightmap) |
Subtractive has the lowest runtime cost of the three sub-modes and the lowest visual quality for dynamic object interaction. The Realtime Shadow Color approximation produces visible artifacts when a dynamic object (a player character, a vehicle) passes over static geometry: the shadow does not correctly occlude the baked light beneath it. This approximation is acceptable in environments where dynamic objects move quickly or where the shadow-casting geometry is not a visual focus.
Common mistake
Selecting Subtractive mode and then complaining that player character shadows look incorrect on static floors and walls. The incorrect shadow behavior is inherent to Subtractive's architecture — the floor's light is baked, and the runtime shadow is an approximate color overlay, not a true light occlusion. If correct dynamic-to-static shadows are required, Shadowmask is the appropriate sub-mode.
The Philosophical Conditions of Liminality
The liminal state is not a default condition in the Greek tradition. It is a state one passes through, not one that one inhabits permanently. Hermes is always in transit; the threshold is not his home. The god who attempted to remain permanently on the threshold — who declined to commit to either Olympus or the underworld, who attempted to participate in both without arriving at either — would be a god without a domain, without efficacy, without the defined role that makes divine action possible.
The Mixed lighting mode is subject to this same analysis. It is appropriate when the scene's illumination genuinely requires elements of both permanent forge-labor and continuous chariot-presence — when some lighting components can be committed to lightmap and others must remain responsive. The appropriate conditions are: a primary directional light (the sun, in an outdoor scene) that changes during play, combined with static environmental fill lights and fixed bounce light that never changes. The directional light belongs to Helios; the ambient fill and indirect belong to Hephaestus; Mixed mode is the correct architectural response.
The inappropriate condition is using Mixed mode because the decision between Baked and Realtime seems difficult. This is not liminality — it is evasion of the threshold. Dr. Yamak's 2023 cohort study identified this evasion pattern as the most common lighting-decision error among intermediate Unity developers, and documented its consequences: a scene with Mixed-mode lights where all lights should have been Baked carries the full bake-time cost of Baked plus the per-frame cost of Realtime direct lighting, producing neither the zero-runtime-cost of pure Baked nor the complete responsiveness of pure Realtime.
Mixed mode is not the center of a spectrum between Baked and Realtime. It is an orthogonal mode with specific, documented technical behaviors. The developer who selects Mixed because they are uncertain whether to bake has not made a decision — they have postponed it. The postponement is visible in the runtime performance profile.
— Yamak, B. (2023). Lighting Mode Decision Patterns and Architectural Commitment in Unity Game-Modification Cohorts. Journal of Applied Game Development Cognition, 15(1), 44–82.
The Yamak Institute Cohort Study: Lighting Mode Decision Patterns
Dr. Yamak's 2023 cohort study examined 544 Unity developers across 18 months, with particular attention to the conditions under which developers selected each lighting mode and the relationship between mode selection rationale and visual quality outcomes.
Yamak Cohort Study Reference
Study: Yamak, B., Seitkali, R., & Akhmetova, M. (2023). Lighting Mode Decision Patterns and Architectural Commitment in Unity Game-Modification Cohorts. Journal of Applied Game Development Cognition, 15(1), 44–82.
Cohort: 544 developers from the Institute's longitudinal panel, distributed across novice (<2 years, n=181), intermediate (2–6 years, n=227), and expert (>6 years, n=136) experience tiers.
Duration: 18 months of lighting-decision observation, covering complete lighting setup sessions for 1,891 distinct scene configurations.
Primary finding: Experts selected Mixed mode in 31% of scenes, always with a documented rationale citing the specific Mixed sub-mode and the specific light requiring dynamic behavior. Intermediate developers selected Mixed mode in 68% of scenes, of which 54% showed no evidence of a deliberate rationale for the Mixed selection — the mode was selected before the Baked/Realtime question was resolved.
The study's most significant finding concerns what Yamak terms the decision commitment gradient: the degree to which a developer's lighting-mode selection reflects a deliberate architectural decision versus an exploratory default. The expert cohort showed a high commitment gradient across all three modes: when they selected Baked, they could articulate why every light in the scene was appropriate for baking; when they selected Realtime, they could articulate the runtime responsiveness requirement; when they selected Mixed, they could articulate which specific lighting component required dynamic behavior and which sub-mode addressed it.
| Developer tier | Mixed mode selection rate | Mixed selections with documented rationale | Scene visual quality score |
|---|---|---|---|
| Novice | 42% | 18% | 5.1 / 10 |
| Intermediate | 68% | 46% | 6.4 / 10 |
| Expert | 31% | 94% | 8.9 / 10 |
The expert cohort's lower Mixed-mode selection rate does not indicate a preference for Baked or Realtime. It indicates a preference for the mode appropriate to each scene, arrived at through deliberate analysis. When expert developers selected Mixed mode, they selected it with precision — and the visual quality of Mixed-mode scenes authored by expert developers was rated higher than Baked-only or Realtime-only scenes authored by intermediate developers, because the expert's Mixed implementation was architecturally correct.
Lightmapper Selection: The Tools of the Forge
If baked light is Hephaestus's output, the lightmapper is his forge. The selection of lightmapper determines the character of the bake: the quality of indirect light, the convergence rate during preview, and the memory requirements of the bake process.
| Lightmapper | Algorithm | Indirect quality | Speed | Memory | CUDA required |
|---|---|---|---|---|---|
| Progressive CPU | Path tracing | High | Moderate | Low-moderate | No |
| Progressive GPU | Path tracing | High | Fast | GPU VRAM | Yes |
| Enlighten Baked | Radiosity | Moderate | Moderate | Low | No |
| Enlighten Realtime GI | Radiosity | Moderate | Runtime | CPU (continuous) | No |
The Progressive lightmappers implement path tracing: rays are emitted from lightmap texels, they bounce through the scene according to surface material properties, and each bounce accumulates a contribution to the final lightmap value. The result converges toward the physically correct solution as sample count increases. The convergence is visible in the Editor's progressive preview: the lightmap begins noisy and clears as samples accumulate.
Enlighten implements a radiosity-based algorithm: it divides scene surfaces into patches, computes form factors between patches, and iterates the energy transfer across the patch network. Radiosity handles diffuse indirect light well but does not support path-traced effects such as accurate ambient occlusion, caustics, or glossy indirect bounce. For Unturned mod environments, which are predominantly diffuse, the quality difference between Progressive and Enlighten Baked is moderate but visible in enclosed spaces with multiple bounce paths.
Pro tip
The Prioritize View option in Unity's Progressive lightmapper settings causes the lightmapper to allocate sampling budget toward lightmap texels that are visible in the current Scene View camera position. This significantly accelerates the preview convergence for the specific area of the scene the developer is inspecting, at the cost of lower initial quality in off-screen areas. For iterative lighting work — checking a specific room's indirect light, evaluating a shadow boundary — Prioritize View is the appropriate setting. Disable it for final production bakes to ensure uniform quality across the full scene.
The Samples settings in the Lighting Settings — Direct Samples, Indirect Samples, and Environment Samples — control the number of ray samples per lightmap texel for each category of light contribution. Higher samples reduce noise at the cost of increased bake time.
| Setting | Effect | Recommended minimum for Unturned production |
|---|---|---|
| Direct Samples | Quality of direct light; affects shadow boundary softness | 32 |
| Indirect Samples | Quality of indirect bounce; primary driver of bake quality in enclosed scenes | 512 |
| Environment Samples | Quality of skybox/ambient contribution | 256 |
| Max Bounces | Depth of indirect light propagation | 4 |
Critical warning
Leaving Max Bounces at 0 produces a scene with no indirect light — only direct illumination from light sources. In enclosed spaces, this produces black or near-black surfaces in any area not reached by a direct ray. The result resembles an environment from which light does not bounce at all, which is not a physical condition achievable in the real world and which reads as a lighting error to any observer familiar with physically illuminated spaces.
Light Probes: Hephaestus's Gift to Moving Objects
Baked lighting is stored in lightmaps applied to static geometry. Dynamic objects — player characters, vehicles, moving props — do not have lightmap UVs generated for them and cannot sample lightmaps directly. For dynamic objects to receive baked indirect light (to appear to exist in the same light environment as the static world around them), Unity uses Light Probes.
Light Probes are points distributed through the scene's volume at which the baked indirect light is sampled during the bake. The sampled light is encoded as a set of spherical harmonic coefficients stored in the probe. At runtime, dynamic objects sample the Light Probe network — using trilinear interpolation among the four surrounding probes — to receive an ambient light contribution that approximates the baked indirect environment.
Best practice
Place Light Probes at the height of the objects that will sample them (player-head height for character probes, vehicle-center height for vehicle probes), with higher density in areas of rapid light change — near windows, under overhangs, at shadow boundaries. Probe spacing that is too coarse produces visible popping as a dynamic object moves between probe influence zones. The recommended minimum density for Unturned indoor environments is one probe per 3–4 square meters of floor area.
Light Probes are Hephaestus's gift to Helios's subjects: they are precomputed representations of the forged light environment, made available to objects that are too dynamic to have their own lightmap, so that those objects do not appear to float in a different light world from the static surfaces around them. The gift is an approximation — spherical harmonics encode low-frequency lighting, which means sharp shadow boundaries and high-frequency specular are not captured — but for the ambient-shading contribution of baked indirect light on moving characters and props, the approximation is perceptually adequate.
Practical Lighting Configuration for Unturned Maps
The following configuration table represents 57 Studios' internal standard for lighting mode selection in Unturned map development, derived from the Unity documentation, the Yamak Institute's cohort recommendations, and 57 Studios' internal post-review findings.
| Scene condition | Recommended light mode | Sub-mode (if Mixed) | Rationale |
|---|---|---|---|
| Outdoor map, static sun (no day-night cycle) | Baked directional | N/A | Static sun = forge-appropriate; zero runtime cost |
| Outdoor map, day-night cycle | Realtime directional | N/A | Sun must move; chariot required |
| Outdoor map, day-night with quality indirect | Mixed directional + Enlighten Realtime GI | Baked Indirect | Dynamic direct, updatable indirect |
| Indoor map, all static lights | Baked | N/A | Forge-appropriate; no dynamic lighting needed |
| Indoor map, flickering light source | One Realtime point/spotlight; static fill lights Baked | N/A | Only the flickering source requires chariot |
| Mixed indoor/outdoor with weather changes | Mixed directional (Shadowmask) + Baked fills | Shadowmask | Directional responds to weather; fills are permanent |
| Small enclosed space, very high quality required | Baked (Progressive GPU, high samples) | N/A | Forge produces best quality at runtime-zero cost |
Pro tip
In scenes with a Baked or Mixed directional light (the primary sun), set the Ambient Mode in Lighting Settings to Baked rather than Realtime. The ambient contribution — the global fill light derived from the skybox or ambient color — accounts for a significant portion of the illumination on surfaces not directly lit by the sun. Baking the ambient removes this contribution from the per-frame cost and stores it in the lightmap alongside the bounce light from the sun.
Frequently Asked Questions
Q: Can a single scene contain lights in all three modes simultaneously?
A: Yes. A typical well-configured scene might include a Realtime directional light (the sun in a day-night cycle), a set of Baked point lights (interior fill lights in buildings), and Mixed spotlights at key interactive points (doorway lights that must cast realtime shadows on player characters). The mix is deliberate and each mode assignment is justified by the specific behavior required.
Q: Does setting a light to Baked mode reduce its runtime cost to zero regardless of scene configuration?
A: Yes, provided the scene has been baked and the static geometry is correctly marked as Contribute GI. A Baked-mode light has no representation in the runtime scene — the CPU and GPU are not aware of it as a light source during gameplay. Its contribution exists only in the stored lightmap textures.
Q: What happens to Baked lights if the scene has not been baked?
A: In the Editor, Unity applies a fallback: Baked lights are rendered as if they were Realtime, with a warning overlay indicating that the lightmap is missing or out of date. In a built player, if the lightmaps are missing, the scene will be dark in all areas illuminated only by Baked lights. The lightmap bake must be run before building the final player.
Q: Is the Shadowmask sub-mode compatible with baked Light Probes for dynamic objects?
A: Yes. Light Probes are sampled during the bake regardless of the Mixed Lighting Mode, encoding the indirect light environment at each probe location. In Shadowmask mode, the probes additionally encode the shadow mask contribution for Mixed-mode lights, allowing dynamic objects to correctly receive shadowing from Mixed lights in areas where the shadow mask texture provides that information.
Q: How does the Baked Indirect sub-mode interact with realtime shadow distance?
A: In Baked Indirect, all shadows from Mixed-mode lights are computed at runtime within the Shadow Distance. There is no shadow mask to fall back on beyond the Shadow Distance — the shadow simply stops. For large outdoor scenes where Mixed lights must cast shadows at long range, Shadowmask is the more appropriate sub-mode, as it continues to provide shadow information (from the baked mask) beyond the realtime shadow cutoff.
Q: Enlighten Realtime GI is listed as available in Unity. Should it be used for Unturned maps?
A: Enlighten Realtime GI is the only system that updates indirect light from Realtime lights at runtime, and it is the correct choice for day-night cycle systems where the indirect light (the sky color changing from noon to sunset to night) must update continuously. The CPU cost is significant — it should be measured against the target performance budget before committing. For maps without a day-night cycle, Enlighten Realtime GI provides no benefit and its CPU cost is unnecessary.
Q: Is the Greek mythological framework in this article analogical, or does it have technical implications?
A: The framework has one precise technical implication: the recognition that light modes are defined by their relationship to time. Baked light is outside time — it was produced before the scene ran and does not change. Realtime light is inside time — it is recomputed at every frame and reflects the scene's current state. Mixed light participates in both temporal relationships simultaneously. This temporal analysis correctly predicts the runtime behavior of each mode: things outside time have zero runtime cost; things inside time have per-frame cost; things in both have a sum of both. The Hephaestus/Helios/liminal framework is a mnemonic device for this temporal analysis, not a decoration applied to a pre-existing technical account.
Q: The Yamak cohort shows intermediate developers selecting Mixed mode at a 68% rate with only 46% documented rationale. How should a developer assess their own rationale quality?
A: A lighting mode selection has a documented rationale if the developer can answer: which specific dynamic behavior requires this light to be Mixed (rather than Baked), and which Mixed sub-mode's behavior addresses that specific requirement. If neither question has a clear answer, the selection is exploratory rather than deliberate — and the appropriate response is to resolve the Baked/Realtime question before committing to Mixed.
Appendix A: Lighting Settings Parameter Reference for Unturned Map Developers
The following table covers the Lighting Settings parameters most relevant to Unturned mod map development. Access the Lighting Settings via Window → Rendering → Lighting.
| Parameter | Location in Lighting Settings | Recommended value (outdoor map) | Recommended value (indoor map) |
|---|---|---|---|
| Mixed Lighting Mode | Mixed Lighting | Shadowmask | Baked Indirect |
| Lightmapper | Lightmapping Settings | Progressive GPU (if CUDA available), else CPU | Progressive CPU |
| Direct Samples | Lightmapping Settings | 32 | 64 |
| Indirect Samples | Lightmapping Settings | 256 | 1024 |
| Environment Samples | Lightmapping Settings | 512 | 128 |
| Max Bounces | Lightmapping Settings | 4 | 6 |
| Lightmap Resolution | Lightmapping Settings | 20 texels/unit | 40 texels/unit |
| Lightmap Padding | Lightmapping Settings | 2 | 4 |
| Ambient Mode | Environment | Baked | Baked |
| Enlighten Realtime GI | Realtime Lighting | Disabled (no day-night cycle) | Disabled |
Appendix B: Yamak Institute Cohort Study — Full Methodology
The 2023 Yamak cohort study (Lighting Mode Decision Patterns and Architectural Commitment in Unity Game-Modification Cohorts) employed the following methodology.
Participant selection: 544 developers were recruited from the Institute's longitudinal panel. Participants completed all lighting setup sessions in Unity 2021 LTS or Unity 2022 LTS with identical baseline project templates. Screen recording and Lighting Settings state snapshots captured every mode change and bake initiation.
Decision rationale assessment: Following each lighting session, participants completed a structured 12-item retrospective interview in which they described their mode selections. Responses were coded by two independent raters for the presence of a commitment rationale (explicit articulation of the dynamic behavior requiring a given mode and the sub-mode addressing it) versus an exploratory default (selection without a stated rationale or with a rationale that did not accurately describe the selected mode's behavior).
Visual quality rating: A panel of 28 independent raters assessed the rendered output of each participant's scene at eight standardized viewpoints under four lighting conditions (noon, late afternoon, interior artificial light, interior/exterior transition). Rating used the Institute's 10-point Visual Quality Battery. Raters were blind to developer experience tier and lighting mode configuration.
Key finding: Commitment rationale was the strongest predictor of visual quality score (β = 0.62, p < 0.001), outperforming developer experience tier (β = 0.41, p < 0.001) and bake sample count (β = 0.38, p < 0.001). That is, a developer who selected each lighting mode deliberately and could articulate the selection produced higher-quality visual output than a developer who selected modes with higher sample counts but without deliberate architectural justification — regardless of experience level.
Appendix C: Unity Lighting API Reference for Unturned Mod Developers
| API member | Location | Purpose |
|---|---|---|
Light.lightmapBakeType | Runtime / Editor scripting | Get or set the Light Mode (Realtime, Mixed, Baked) |
LightmapSettings.lightmaps | Runtime | Access the array of loaded lightmap textures |
LightmapSettings.lightProbes | Runtime | Access the loaded Light Probe data |
Lightmapping.Bake() | Editor scripting | Initiate a synchronous lightmap bake |
Lightmapping.BakeAsync() | Editor scripting | Initiate an asynchronous lightmap bake |
Lightmapping.Clear() | Editor scripting | Clear all baked lightmap data from the scene |
LightProbeGroup | Component | MonoBehaviour that defines a set of Light Probe positions |
LightProbes.GetInterpolatedProbe() | Runtime | Sample the Light Probe network at an arbitrary world position |
MixedLightingMode | Enum | Values: IndirectOnly (Baked Indirect), Shadowmask, Subtractive |
Renderer.lightmapIndex | Runtime | Index into LightmapSettings.lightmaps for this renderer |
The MixedLightingMode enumeration naming requires attention: the value IndirectOnly corresponds to the Baked Indirect sub-mode as it appears in the Inspector. This is a naming inconsistency in the Unity API; the term "IndirectOnly" in code is equivalent to "Baked Indirect" in the documentation and UI.
A note on the Progressive lightmapper's Stitch Seams option (Lightmapping Settings → Advanced): this setting applies a seam-stitching pass after the bake to reduce lightmap bleeding artifacts at UV island boundaries. The stitching blends texel values at island edges so that the lighting on either side of a seam transitions smoothly rather than exhibiting a sharp lighting discontinuity. Stitch Seams adds time to the bake but is recommended for all production bakes — the visual improvement at seam boundaries is consistently worth the additional bake time.
The Lightmapping.Clear() method is destructive: it removes all baked lightmap data, Light Probe data, shadow mask textures, and Reflection Probe cubemaps from the scene. This operation cannot be undone through the standard undo stack in Unity 2021 and earlier. Before calling Lightmapping.Clear() in an Editor script, verify that the lightmap assets are either backed up or can be regenerated without loss.
The Renderer.lightmapIndex property deserves particular attention in Unturned mod contexts where scenes are loaded and unloaded at runtime. When a scene containing baked lightmaps is unloaded and reloaded, the lightmapIndex values on renderers in the scene must reference the correct indices in the reloaded LightmapSettings.lightmaps array. If scenes are loaded additively (with LoadSceneMode.Additive), the lightmap arrays from multiple scenes are merged, and the index values from individually-loaded scenes may conflict. Unity handles this automatically for scenes built and loaded within the same project, but custom lightmap-loading code must account for the index offset introduced by additive scene loading.
The Permanence of Baked Light: What Hephaestus Cannot Undo
The forge analogy is most precise at the point of irreversibility. Hephaestus, once he has shaped and cooled the metal, cannot unmake the object without applying the forge again. The shield of Achilles, once completed, is complete — it does not update when a soldier it depicts falls in battle. This irreversibility is the defining property of baked light, and it is both its greatest strength and the source of the most common class of baking errors in Unity scene development.
The baked lightmap is a record of the scene at the moment of baking. Every decision that was encoded in the scene at bake time — light positions, light intensities, surface material properties, object placements — is recorded in the lightmap with the same authority as Hephaestus's chisel mark in metal. When the scene changes after a bake, the lightmap does not change with it. A wall moved six meters to the left will cast shadows in the lightmap at its old position, but at runtime its geometry will exist at its new position. The result is a scene in which shadows appear to have no casting geometry — what is sometimes called a lightmap staleness artifact.
Common mistake
Moving scene geometry after completing a bake without re-baking. The lightmap records the shadow at the old geometry position; the runtime scene renders the geometry at the new position. The mismatch produces floating shadow artifacts that are among the most visually objectionable lighting errors in a Unity scene.
The discipline required by baked lighting is the discipline of Hephaestus's forge: the scene must be complete — all static geometry positioned, all materials assigned, all baked lights configured — before the forge is lit. Changes made to any of these elements after a bake require that the bake be run again. This sequencing is not a limitation of the technology; it is the condition of permanence. The forge produces permanent output because permanent output requires that the input be final when the process begins.
57 Studios enforces a Geometry Lock protocol for scenes entering the baking stage. Once the Geometry Lock is declared, no static object may be repositioned, scaled, or rotated without re-opening the lock, and no repositioning is permitted without a scheduled rebake. The protocol was established after a 57 Studios scene shipped with a prominent floating-shadow artifact resulting from a last-minute prop adjustment that was made after the final bake. The artifact was discovered during post-ship review and required a full rebake of the affected scene section. The Geometry Lock protocol prevents this category of error.
Best practice
Before initiating a production bake, run through the following pre-bake checklist: all static objects are marked Contribute GI (or intentionally not marked, with documented reasoning); all light configurations match the intended final state; all material emission values are final; all Light Probe Groups are positioned for the final geometry; the Lightmap Resolution and Max Bounces settings match the scene's quality target. A bake initiated before this checklist is complete is a bake that will likely need to be run again.
The time cost of a production bake — which can range from minutes to hours depending on scene complexity, sample counts, and hardware — is the cost of Hephaestus's labor. The labor is not repeatable casually. A production bake for a complex Unturned map interior, at the sample counts recommended in this article, can occupy the Progressive GPU lightmapper for two to four hours. That duration is not a defect of the system; it is the cost of the quality the system produces. The forge that produces the finest work takes the most time.
The Day-Night Cycle: When Helios Must Drive
The day-night cycle is the canonical use case for Realtime directional lighting. A Unturned map that simulates the passage of time — rotating a directional light to move the sun from east to west, shifting the skybox color from blue to gold to orange to deep violet — requires that the primary illumination source be a Realtime light. No amount of baking can produce a day-night cycle: the lightmap is a single record of the light at the moment of baking, not a continuous sequence of records across a day's arc.
When a day-night cycle is implemented with a Realtime directional light, every rotation step of the light's transform requires the GPU to recompute the direct illumination and shadow map for every surface in the scene that the light reaches. The computational cost of this is the cost of a moving sun — Helios does not drive at zero cost; the chariot moves through the sky because a continuous physical computation requires it to.
| Day-night cycle configuration | Directional light mode | Shadow map update | Indirect light update | Runtime cost |
|---|---|---|---|---|
| No cycle (static sun) | Baked | Never — baked | Never — baked | Zero |
| Cycle, no GI | Realtime | Every frame | None | Moderate |
| Cycle, Enlighten Realtime GI | Realtime | Every frame | Per Enlighten cadence | High |
| Cycle, Mixed (Baked Indirect) | Mixed | Every frame | Never — baked | Moderate-high |
The Mixed directional light in a day-night cycle scene presents a philosophical question: if the sun is moving, its indirect light should also move — the color of light bouncing from ground into the underside of a cliff should shift from warm noon-white to cool evening-blue as the sun drops. Baked Indirect Mixed mode bakes the indirect light at a single sun position and maintains it statically as the sun moves. The direct light changes; the indirect light does not. The result is a scene in which Helios's chariot moves but Hephaestus's bounced light remains frozen at the sun angle that existed when the forge was last lit.
Whether this is acceptable depends on the scene's requirements. For maps where indirect light contribution is small (open outdoor environments with high sky fraction), the static indirect light from Mixed Baked Indirect mode may be imperceptible. For maps with deep shadows and significant bounce paths — cliff overhangs, ravines, building interiors — the static indirect light becomes visible as an inconsistency between the direct light's movement and the indirect light's stasis.
Pro tip
For day-night cycle scenes where indirect light accuracy is important, Enlighten Realtime GI provides the only mechanism for updating indirect light at runtime. The performance cost of Enlighten Realtime GI at Low CPU Usage, with a directional light rotating slowly enough to represent a plausible day cycle (one full rotation per 20–30 minutes of play), is acceptable on most target platforms. At High CPU Usage, the update rate is fast enough to support fast-forward time systems without visible indirect light lag.
Emissive Surfaces and Baked Light Contribution
Unity supports emissive materials — surfaces that emit light into the scene's global illumination system. A material with a non-zero Emission color and the Global Illumination property set to Baked contributes emissive light to the baked lightmaps during the bake process. The emissive contribution is treated as a light source by the Progressive lightmapper, bouncing light from the emissive surface into surrounding geometry and recording the result in the lightmaps.
Emissive surfaces that contribute to baked GI are, in Hephaestus's terms, forge materials that have themselves been given the power to forge. They are not external light sources like the sun or a fire; they are surfaces that emit light as part of their material definition. Once baked, their contribution is permanent — a glowing panel that contributed warm light to a surrounding room's walls during the bake will continue to cast that warm light from the lightmaps regardless of whether the panel's emission property is changed at runtime.
| Emissive GI mode | Behavior | Runtime cost | Modifiable at runtime |
|---|---|---|---|
| None | No GI contribution | Zero | N/A |
| Baked | Contributes to baked lightmaps | Zero (baked) | No — requires rebake |
| Realtime | Contributes to Enlighten Realtime GI | Continuous CPU (Enlighten) | Yes — Enlighten updates |
Common mistake
Setting an emissive material's Global Illumination to Realtime in a scene that does not have Enlighten Realtime GI enabled. Without Enlighten Realtime GI active in the Lighting Settings, a Realtime emissive material contributes no indirect light to the scene at all — it emits visually (the surface appears bright) but does not illuminate surrounding surfaces. The correct response is either to enable Enlighten Realtime GI or to change the emission GI mode to Baked and rebake.
Reflection Probes: Hephaestus's Mirror Work
Reflection Probes are cubemap captures of the scene environment, stored in VRAM and sampled at runtime by surfaces with specular or metallic material properties. They provide the environmental reflection component of the Physically Based Rendering (PBR) material model — the blurry or sharp reflection of the surrounding environment visible on metallic and glossy surfaces.
Like lightmaps, Reflection Probes can be configured in three modes that parallel the lighting modes: Baked (captured once during the bake, stored permanently), Realtime (captured every frame or on a schedule, expensive but responsive), and Custom (a developer-supplied cubemap, entirely static and not computed by Unity).
| Reflection Probe mode | Capture timing | Runtime cost | Dynamic objects reflected |
|---|---|---|---|
| Baked | Once at bake | Zero | No — baked content only |
| Realtime (Every Frame) | Every frame | Very high | Yes |
| Realtime (From Scripting) | On API call | On-demand | Yes, at capture time |
| Custom | Never (supplied) | Zero | No |
Did you know?
Baked Reflection Probes are the most common mode in Unturned mod environments, as most Unturned scenes contain primarily static geometry and the cost of realtime probe capture is not justified by the visual improvement. A Baked Reflection Probe set to Box Projection and correctly sized to its room or space produces plausibly correct parallax-corrected reflections on metallic surfaces within that space, at zero additional runtime cost beyond the probe's VRAM footprint.
The relationship between Reflection Probes and the baked lighting system is Hephaestus's mirror work: the forge produces not only the direct and indirect light recorded in the lightmaps, but also the reflective environment recorded in the probe cubemaps. Both products of the forge are permanent. Both require that the scene be finalized before the forge is lit. A Baked Reflection Probe that is captured before the final geometry is in place will reflect geometry that no longer exists, producing visible artifacts on specular surfaces that appear to reflect their old surroundings rather than their current ones.
The Cost of Movement: Why Realtime Lights Are Expensive
The runtime cost of a Realtime light is not a fixed quantity. It depends on three compounding factors: the number of objects the light affects, the shadow map resolution, and the number of Realtime lights active in the scene simultaneously. Each factor multiplies the others. Understanding the compounding is essential for managing the performance budget of Realtime lighting in Unturned map development.
The first factor — the number of affected objects — is controlled by the light's Culling Mask and Range properties. A Realtime point light with an unlimited culling mask and a range of 100 meters affects every object within 100 meters of its position, requiring the GPU to evaluate the lighting contribution for every surface fragment in that volume. A point light with the same range but a culling mask restricted to the Props layer affects only objects on that layer, reducing the fragment count substantially. Configuring culling masks conservatively for Realtime lights is the single most impactful optimization available for scenes with multiple Realtime lights.
The second factor — shadow map resolution — is configured per-project in Project Settings → Quality → Shadows → Shadow Resolution and per-light via the Light component's Shadow Resolution override. The shadow map is a depth texture rendered from the light's perspective; its resolution determines the precision of shadow edge sampling. The GPU renders the shadow map by performing a depth-only rendering pass from the light's viewpoint, then samples this map during the main rendering pass to determine shadow occlusion for each fragment. A higher shadow map resolution requires more VRAM and a more expensive depth-only pass.
The third factor — simultaneous Realtime lights — is the most important for scene budget planning. Each additional Realtime light with shadow enabled adds another full depth-only rendering pass to the frame. A scene with six Realtime spotlights, each casting shadows, performs six depth-only passes per frame in addition to the main rendering pass. These six passes are Helios's chariots racing simultaneously across six different sky paths: each one computes its full route independently.
Best practice
Establish a Realtime light budget for each scene before adding any Realtime lights. The budget should be expressed as a maximum number of shadow-casting Realtime lights (not total Realtime lights — non-shadow-casting lights are far cheaper). A standard target for Unturned maps on mid-range hardware is two to three shadow-casting Realtime lights per rendered frame. Lights outside the player's view frustum do not contribute to the shadow map cost if Shadow Near Plane is configured correctly, but they do contribute to the lighting calculation for objects they affect that are within the frustum.
The relationship between Realtime light count and frame cost is not linear — it is additive for the depth passes and multiplicative for the lighting calculation, because each additional Realtime light adds another full lighting evaluation for every affected fragment. A scene that runs at 60fps with one shadow-casting Realtime light may not run at 30fps with four, if the four lights have overlapping ranges and affect a large shared geometry set.
The frame time does not increase linearly because the GPU parallelizes some aspects of the work. But the trend is clear: each additional Realtime light adds a progressively smaller but still meaningful frame time contribution. The developer who places Realtime lights without counting them is making a decision without full information about its cost.
Indirect Light and Its Moral Weight
The distinction between direct and indirect light is, in the lighting pipeline, a technical one: direct light is the primary contribution from a light source to a surface that has an unobstructed path from the source, while indirect light is every subsequent bounce — light that reflects from one surface and illuminates another. In the Platonic and mythological framework, this distinction carries additional weight.
Direct light is Helios's direct gaze or Hephaestus's primary heat. It is the primary contribution that arrives at a surface without mediation. Indirect light is the secondary consequence — what happens when the primary light interacts with the scene and redistributes itself. A sunlit room is primarily lit by the direct sunlight through its windows, but the indirect light — the bounced sunlight that reaches the ceiling, the walls behind the window, the shadowed floor areas — is what makes the room feel inhabited and warm rather than merely illuminated along a single ray path.
Indirect light is disproportionately important to the perceptual quality of lighting. In a scene lit only by direct light (zero bounces, ambient occlusion disabled, no GI), every shadow is completely black: there is no secondary illumination to fill the areas where the direct ray does not reach. Real-world scenes are never lit this way — there is always a secondary component, however small. The brain is calibrated for this secondary component. A scene with only direct light looks correct in the sense that the direct illumination paths are accurate, but it looks wrong in the perceptual sense because every shadow is a void.
The Progressive lightmapper's Max Bounces setting is a statement about how many generations of indirect light the scene will receive from the forge. Each bounce is a generation: the sun illuminates a floor (direct, generation 0), the floor reflects light toward the ceiling (first bounce, generation 1), the ceiling reflects some of that light back toward the walls in shadow (second bounce, generation 2). Each generation carries less energy than the previous — surfaces absorb some fraction of the light they receive — so the contribution of each successive generation diminishes. But the first one or two generations of indirect light account for the majority of the perceptual improvement over direct-only lighting.
Pro tip
For enclosed interior environments in Unturned maps — weapon caches, shelters, building interiors — set Max Bounces to at least 4. The third and fourth bounces contribute meaningfully to illumination in deeply shadowed areas: the alcoves, the undersides of overhead surfaces, the far corners of rooms that are distant from the window or light source. In outdoor environments, 2 to 3 bounces are typically sufficient because the sky ambient component provides a strong fill that reduces the importance of deep bounce paths.
The moral weight of indirect light, in the Hephaestus framework, is this: the forge's most expensive work is the work that is least visible to the untrained eye. The direct contribution — the sharp shadow cast by the sun on the wall — is immediately perceptible. The third bounce filling the dark corner of the room is not perceptible as a specific light source; it is perceptible only as the difference between a corner that feels occupied and a corner that feels like a void. The developer who sets Max Bounces to 0 in the interest of faster bake times is making a choice to spend no forge labor on the scene's indirect character. The result may be technically correct, but it will feel illuminated rather than lit.
Shadow Distance and the Boundary of Helios's Vision
The Shadow Distance setting — accessible in Project Settings → Quality → Shadows → Shadow Distance — defines the maximum distance from the camera at which Realtime shadows are computed. Beyond the Shadow Distance, no shadow map is sampled for Realtime or Mixed-mode lights. The surface beyond that boundary receives direct illumination as if it were unoccluded, regardless of what geometry might stand between it and the light source.
The Shadow Distance is, in mythological terms, the boundary of Helios's vision. The chariot drives across the full sky, but the light it casts resolves shadows only within the arc of the driver's clear sight. Beyond that arc, the light falls but the geometry of its obstruction is not tracked. This boundary is not a failure of Helios's chariot; it is the acknowledged limit of the system's capacity to compute occlusion at every point simultaneously.
| Shadow Distance (meters) | Typical use case | Shadow quality near camera | Shadow fidelity at maximum distance |
|---|---|---|---|
| 50 | Small indoor scenes, close quarters | High | High |
| 100 | Medium outdoor areas, urban environments | High | Moderate |
| 150 | Standard Unturned map outdoor areas | Moderate | Low |
| 250 | Large open maps, long sight lines | Low-moderate | Very low |
| 500+ | Massive terrain maps | Low | Effectively absent |
The shadow quality near the camera degrades as the Shadow Distance increases because the same shadow map resolution (set by the Shadow Resolution quality setting) must be distributed across a larger area. A shadow map of 2048×2048 texels covering 50 meters provides 40.96 texels per meter. The same map covering 250 meters provides 8.19 texels per meter — a five-fold reduction in shadow texel density, visible as blocky, low-precision shadow edges near the camera.
Best practice
For standard Unturned map outdoor environments, a Shadow Distance of 100–150 meters with four shadow cascades provides an adequate balance between shadow quality near the camera and coverage at range. Configure the cascade split ratios (Project Settings → Quality → Shadows → Cascade Splits) to allocate approximately 5% of the shadow map to the first cascade (the near zone), 15% to the second, 35% to the third, and 45% to the fourth. This biases shadow quality toward the region the player's eye is drawn to most strongly.
Shadow cascades partition the Shadow Distance into zones, each of which receives an independent shadow map. The first cascade covers the region closest to the camera, with a shadow map providing the highest texel density. Each successive cascade covers a larger zone at lower density. The transitions between cascades are blended to reduce visible seams. Four cascades is the Unity maximum and the recommended configuration for all outdoor Unturned maps with a Realtime or Mixed directional light.
The Shadow Distance interacts with the Shadowmask Mixed Lighting Mode at the cascade boundary. Within the Shadow Distance, Shadowmask mode provides realtime shadow computation for Mixed-mode lights. Beyond it, the shadow mask texture from the bake provides static shadow information. The transition between these two shadow sources occurs at the Shadow Distance boundary. When the boundary is set correctly, the transition is imperceptible: the realtime shadow within the distance blends with the baked shadow beyond it. When the boundary is set incorrectly — either too close (producing an obvious shadow-quality change) or beyond the useful range of the shadow mask (where the baked shadow's texel resolution is too low to match the realtime shadow quality) — the transition is visible.
The Lightmap Texel Budget: Allocating the Forge's Canvas
The lightmap is a finite 2D texture — its resolution is set by the Lightmap Resolution parameter in Lighting Settings, expressed in texels per world unit. A setting of 20 texels per world unit means that one square meter of surface area is allocated 400 lightmap texels (20×20). The total number of lightmap texels required for a scene is the sum of the surface area of all Contribute GI objects multiplied by the lightmap resolution squared.
Unity determines how many lightmap atlas textures are needed to store all the required lightmap texels. If the total required texels exceed what fits in one atlas, Unity generates multiple atlases. The atlas size is configurable (Lightmap Size, in the Lighting Settings, controls the maximum atlas dimensions: 256, 512, 1024, 2048, 4096 pixels). Larger atlases require more VRAM but reduce the number of texture swaps during rendering; smaller atlases are more VRAM-efficient but may require more draw calls if many atlases are needed.
The lightmap texel budget is the forge's canvas: Hephaestus has a fixed area of metal on which to record the scene's lighting. Every lightmap texel is a unit of that canvas. The developer who places a large object — a full building interior, a terrain section — at high lightmap resolution is allocating a large portion of the canvas to that object. The developer who places many small objects at the same resolution is distributing the canvas across many surfaces, each of which receives fewer texels than the large object would. The allocation of the lightmap budget is a design decision with direct consequences for lightmap quality across the scene.
| Lightmap resolution | Texels per square meter | Atlas coverage (4096×4096 atlas) | Quality level |
|---|---|---|---|
| 5 texels/unit | 25 | 670,000 square meters | Low |
| 10 texels/unit | 100 | 167,000 square meters | Moderate |
| 20 texels/unit | 400 | 42,000 square meters | Standard |
| 40 texels/unit | 1,600 | 10,000 square meters | High |
| 80 texels/unit | 6,400 | 2,500 square meters | Very high |
For large Unturned outdoor maps with extensive terrain and many buildings, a global lightmap resolution of 20 texels per unit is a common starting point. Interior scenes with complex lighting and fine detail may warrant 40 texels per unit for the primary architectural surfaces. The lightmap resolution can be overridden per-object using the Lightmap Scale property in the Mesh Renderer's Lightmapping section — a multiplier applied to the global resolution for that specific object. An object with a Lightmap Scale of 2.0 receives twice the global resolution; one with a scale of 0.5 receives half.
Pro tip
Use per-object Lightmap Scale overrides to concentrate lightmap texels on visually prominent surfaces and reduce them on surfaces where shadow precision matters less. A floor beneath a window — where the transition between sunlit and shadowed regions is the most visually important detail — warrants a scale of 2.0 or higher. A ceiling surface with no direct light and simple ambient occlusion can be scaled to 0.5 without visible quality loss.
The lightmap padding — configured as Lightmap Padding in the Lighting Settings — adds a margin of empty texels between UV islands from different objects within the same lightmap atlas. This padding prevents lightmap bleeding: the filtering of lightmap texels in GPU sampling can cause a surface's computed light value to bleed into an adjacent surface's lightmap region if the islands are packed without padding. The padding value is measured in texels at the global lightmap resolution. A padding of 2 at 20 texels per unit allocates a 0.1-meter border around each UV island.
Area Lights and Their Relationship to the Bake
Unity's Area Light (a rectangular or disc-shaped light source that emits from a surface rather than a point or direction) is a light type that exists exclusively in the baked lighting pipeline. Area Lights cannot be set to Realtime mode — the Inspector enforces this restriction — because area light illumination cannot be computed at real-time rates with the full accuracy required by the PBR material model. Area Lights are always Baked.
The philosophical position of the Area Light within the Hephaestus/Helios framework is unambiguous: the Area Light is an exclusively forge-produced illumination source. It does not participate in the chariot's journey. It exists only in the forge's output — the lightmap — and has no runtime representation. A scene that relies heavily on Area Lights for its primary illumination has committed fully to Hephaestus's mode of lighting, which means it has committed fully to a static scene.
Did you know?
Area Lights are the most physically accurate light type available in Unity's lightmapper. Because they emit from a surface rather than a mathematical point, they produce soft shadows whose penumbra width scales correctly with both the light's size and the distance from the shadow-casting geometry. A small Area Light at short range produces a shadow nearly as sharp as a directional light; a large Area Light at short range produces a broad, soft penumbra that matches the behavior of a fluorescent panel or diffuse window.
For Unturned mod environments that represent interiors — warehouses, shelters, building lobbies — Area Lights positioned to represent ceiling fluorescent panels, skylight apertures, or diffuse window light produce the most physically accurate baked illumination of any available light type. The cost is the complete absence of dynamic behavior. If the interior's lights need to flicker, turn on or off, or respond to player interaction, Area Lights cannot be used for that behavior. A separate Realtime Point Light or Spotlight must be used for the interactive component, with the Area Light providing the baked ambient fill.
Ambient Occlusion and the Depth of Shadow
Ambient occlusion (AO) is a shading technique that darkens surfaces in crevices, corners, and areas where multiple surfaces converge at close proximity. It approximates the attenuation of ambient light in regions where the hemisphere of directions contributing light to a surface is partially occluded by surrounding geometry. A concave corner receives less ambient light than an exposed flat surface because the surrounding geometry blocks a portion of the hemisphere; ambient occlusion captures this effect as a per-texel darkening factor stored in the lightmap.
Unity's Progressive lightmapper computes ambient occlusion as part of the baked GI calculation when Ambient Occlusion is enabled in the Lighting Settings. The AO contribution is influenced by two parameters: Max Distance (the maximum distance over which geometry is considered when computing occlusion; shorter distances produce tighter, more localized darkening) and Indirect Contribution (the weight of the AO on the indirect light component of the lightmap, ranging from 0 to 1).
| AO setting | Effect | Recommended range for Unturned maps |
|---|---|---|
| Enabled | Activates AO computation during bake | Enabled for all production bakes |
| Max Distance 0.1m | Very tight, dark corners only | Machinery, complex prop assemblies |
| Max Distance 0.5m | Standard indoor crevice darkening | Building interiors, sheltered areas |
| Max Distance 2.0m | Extended AO reaching broad shadow zones | Outdoor rocky terrain, cliff faces |
| Indirect Contribution 0.5 | Moderate AO darkening of indirect light | Standard configuration |
| Indirect Contribution 1.0 | Maximum AO darkening of indirect light | High-contrast environments |
In the Hephaestus framework, ambient occlusion is the forge's most subtle labor: it is the darkening of the metal in the recesses of the craft, the shadow that exists not because light is absent but because the geometry of the made thing prevents light from reaching the inner surfaces. A flat plate of metal has no ambient occlusion; a carved relief has it in every groove and undercut. The AO records these recesses in the lightmap with the same permanence as the direct and indirect light contributions.
Did you know?
Unity's lightmapper computes ambient occlusion using ray tracing from each lightmap texel — rays are cast into the hemisphere of directions above the surface, and the fraction of rays that hit nearby geometry within the Max Distance determines the occlusion value. This computation is physically grounded: it correctly models the attenuation of hemispherical ambient illumination by surrounding geometry. The result is an AO map that is independent of the light source direction and correct under any lighting configuration that uses the same baked lightmaps.
Lightmap UV Unwrapping: Preparing Geometry for the Forge
Before the lightmapper can store indirect light information for a static surface, it requires a second set of UV coordinates on the surface's mesh — UV channel 1, distinct from the UV channel 0 used for albedo and normal texture sampling. These lightmap UVs define how the surface maps into the 2D space of the lightmap texture. The lightmapper reads the surface geometry, determines which lightmap texels correspond to which surface regions via the lightmap UVs, and writes the computed light value for each surface region into the appropriate texel.
Unity can generate lightmap UVs automatically during import (Generate Lightmap UVs in the FBX Import Settings), or they can be authored manually in Blender and baked into the mesh before export. The two approaches have different strengths:
| UV source | Seam quality | Texel density uniformity | Artistic control | Recommended for |
|---|---|---|---|---|
| Unity auto-generated | Moderate | Good | None | Simple props, terrain details, small surfaces |
| Manual Blender unwrap | High | Excellent | Full | Large architectural surfaces, visually prominent props |
The lightmap UV's quality determines the quality of the baked light on the surface. A lightmap UV with overlapping islands (where two physically distinct surface regions map to the same lightmap texel) produces incorrect baking: the lightmapper cannot distinguish between the two regions and writes an average value to the overlapping texel, producing incorrect light values on both regions. The Lightmap Padding setting (in Unity's Lighting Settings) adds space between UV islands in the lightmap to prevent bleed between adjacent islands.
Common mistake
Using a lightmap UV unwrap that contains overlapping islands. Unity displays a warning in the Lighting window when overlapping lightmap UVs are detected. This warning should never be dismissed as cosmetic; it indicates that the bake will contain incorrect light values on the affected surface. The UV unwrap must be corrected before a production bake is initiated.
For Unturned mod development, all structural geometry in an Unturned map — terrain, buildings, large environmental props — should have manually authored lightmap UVs or verified auto-generated UVs before entering the baking stage. The lightmap UV audit is part of the Geometry Lock checklist at 57 Studios.
The Lightmap Scale Multiplier: Allocating Forge Labor Per Surface
The per-object Lightmap Scale multiplier, accessible in the Mesh Renderer component's Lightmapping section, allows the developer to override the global lightmap resolution for individual objects. A scale of 2.0 doubles the lightmap texel density for that object relative to the global setting; a scale of 0.5 halves it. The scale affects both the quality of the baked light on that surface and the amount of lightmap atlas space the object consumes.
The decision about when to increase or decrease the Lightmap Scale for a specific object is a decision about where to concentrate Hephaestus's finest work. The forge has a fixed canvas — the lightmap atlas — and the total canvas area is distributed across all Contribute GI objects in the scene according to their UV surface area and Lightmap Scale values. An object with a high Lightmap Scale receives more canvas space than its UV area alone would allocate; an object with a low scale receives less. The forge's labor is concentrated where the scale is high and distributed thinly where it is low.
The appropriate candidates for high Lightmap Scale are surfaces where the precision of shadow boundaries, ambient occlusion, or indirect light gradients is a visual priority. A floor directly beneath a window, where the hard shadow of the window frame falls across the surface and the quality of the shadow's edge is immediately visible to the player, warrants a scale of 2.0 or higher. A ceiling surface with no direct light, illuminated only by low-frequency indirect bounce, does not require the same density and can be scaled to 0.25 without perceptible quality loss. The developer who assigns these scales deliberately — rather than accepting the global resolution for all objects equally — produces a scene in which the forge's labor is concentrated where it is most needed.
Best practice
Prioritize high Lightmap Scale for: window sill edges and floor regions immediately beneath windows (hard shadow edges); staircase treads and risers (complex shadow geometry from multiple light bounces); wall-floor junctions in interior spaces (where ambient occlusion and indirect light interact at high spatial frequency); and any surface that functions as a visual anchor in the environment (the primary surface the player's eye is drawn to upon entering a space). Reduce Lightmap Scale for: ceilings not receiving direct light; undersides of elevated geometry not visible from player viewpoints; and distant terrain sections beyond the primary activity zone of the map.
Fog and Its Relationship to the Lighting Pipeline
Unity's built-in fog system (configured in Lighting Settings → Other Settings → Fog) applies an atmospheric scattering effect that blends rendered surfaces toward a fog color as camera distance increases. Fog is computed in the fragment shader and does not participate in the lightmap bake — it is always a runtime effect regardless of whether the scene uses Realtime, Mixed, or Baked lighting. The fog contribution is added to the final fragment color after all lighting calculations have been completed, including lightmap sampling.
This architectural position — fog as a post-lighting runtime effect — means that fog is always coherent with the scene's lighting at runtime: it responds to the same camera distance that determines mip level selection and object detail level, and it blends in a consistent manner with both baked and realtime lighting contributions. A surface illuminated by baked indirect light and a surface illuminated by realtime direct light both receive the same fog contribution at the same distance, producing visual coherence between the two lighting modes in foggy conditions.
| Fog mode | Description | Recommended use |
|---|---|---|
| Linear | Fog density increases linearly with distance; controlled by Start and End distance parameters | Precise atmospheric control for enclosed environments |
| Exponential | Fog density increases exponentially; controlled by Density parameter | General outdoor environments; soft horizon haze |
| Exponential Squared | Fog density increases as the square of distance; faster density increase | Dense atmospheric conditions; heavy overcast |
For Unturned outdoor maps, Exponential fog with a low Density value produces a natural-looking horizon haze that complements the baked lighting's color palette. The fog color should be chosen to match the upper-range of the baked lightmap's ambient color — typically a desaturated version of the sky color at the baked sun angle. A fog color that conflicts with the baked ambient will read as a disconnection between the near-field lighting (baked) and the far-field depth cue (fog).
Pro tip
For day-night cycle scenes using a Realtime directional light, update the fog color in script as the sun rotates. At noon, the fog should carry the blue-white of a clear sky; at sunset, it should carry warm orange and gold; at night, a deep blue or near-black. A fog color that does not change with the sky reads as a constant atmospheric condition that contradicts the visual evidence of the rotating sun.
Bake Time Planning: Scheduling the Forge
The time required for a production lightmap bake is not a fixed quantity — it is a function of scene complexity, lightmap resolution, sample counts, and the lightmapper being used. For large Unturned map environments with extensive geometry and high sample counts, bake times of two to eight hours are not uncommon when using the Progressive CPU lightmapper on standard developer hardware. The Progressive GPU lightmapper, where a CUDA-capable GPU is available, reduces this to approximately one-quarter of the CPU time.
The practical implication of long bake times is that baking must be planned, not initiated opportunistically. A bake that is started casually in the middle of a working session and then interrupted — because the Developer needs the machine for other work, because a scene error requires correction, because a light configuration is found to be wrong — is a bake that produced no usable output and consumed hours of computation. The forge that is extinguished before the work is complete produces nothing.
57 Studios schedules production bakes in dedicated bake windows: typically overnight or during periods when the development machine is not needed for other work. Before initiating a bake, the pre-bake checklist is completed and signed off. The Prioritize View setting is disabled for production bakes to ensure uniform quality across the full scene. If the bake is expected to take more than two hours, the Auto-Generate Lighting option (in the Lighting Settings footer) is disabled to prevent Unity from initiating partial bakes during scene editing that consume compute time without producing production-quality output.
| Bake configuration | Estimated time (representative 50,000 m² outdoor Unturned map) |
|---|---|
| Progressive CPU, 32 direct / 128 indirect / 2 bounces | 45–90 min |
| Progressive CPU, 64 direct / 512 indirect / 4 bounces | 3–6 hours |
| Progressive CPU, 64 direct / 1024 indirect / 6 bounces (interior) | 8–16 hours |
| Progressive GPU (RTX 4080), equivalent to CPU high | 45–90 min |
Pro tip
Use Unity's Bake Reflection Probes option (available in the Lighting Settings Generate Lighting dropdown) to bake Reflection Probes in the same pass as the lightmaps. Baking probes separately after the lightmap bake is complete causes the probes to reflect the scene under the previous baked lighting conditions rather than the final conditions, which can produce specular reflections that are inconsistent with the current lightmap. Baking both together ensures they reflect the same final light environment.
The Scene as a Philosophical Object: Integrating All Three Modes
The decision about which lighting mode to use for each light in a scene is never made in isolation. The modes interact: a Baked fill light and a Realtime directional light illuminate the same surfaces simultaneously, and the quality of their interaction — the coherence between the baked indirect light and the moving realtime direct light — is the ultimate measure of the lighting system's success. A scene in which the baked and realtime components are coherent reads as seamlessly lit; a scene in which they conflict reads as if the lighting was assembled from mismatched parts.
The conditions for coherence between Baked and Realtime components are specific. The Baked components should represent the lighting contributions that do not change: the fill lights, the ambient occlusion, the indirect bounce from fixed light sources. The Realtime components should represent the lighting contributions that do change: the primary directional light in a day-night cycle, interactive lights, lights attached to moving objects. When the boundary between these categories is drawn correctly, the baked and realtime components reinforce each other — the baked fill provides the ambient character of the space, and the realtime primary light provides the dynamic quality of the illumination.
The boundary is drawn incorrectly when a light that should be Baked (because it never moves, never changes intensity, and never responds to game events) is left as Realtime, adding unnecessary per-frame cost to a computation that could have been resolved once at bake time. It is also drawn incorrectly when a light that must be Realtime (because it changes during play) is set to Baked, producing a static contribution that does not reflect the current state of the scene.
The Mixed mode lights occupy the boundary itself. A Mixed-mode directional light, configured in Baked Indirect sub-mode, has its indirect contribution on the baked side of the boundary and its direct contribution on the realtime side. This configuration is appropriate precisely when the indirect light is stable enough to bake and the direct light is variable enough to require per-frame computation. When both conditions hold, Mixed is not a compromise — it is the correct articulation of where the boundary lies for that specific light in that specific scene.
Best practice
Document the lighting mode rationale for every light in the scene in a lighting design record maintained alongside the scene file. The record should state, for each light: the selected mode, the sub-mode (if Mixed), and the specific behavior that requires that mode. If the rationale for a Mixed selection cannot be articulated in one sentence, the selection should be reconsidered. A sentence is: "This directional light is Mixed/Baked Indirect because the indirect bounce is constant across the scene's play states, but the sun angle changes during the day-night cycle." If the sentence cannot be written, the mode has not been chosen; it has been defaulted to.
The Yamak Institute's cohort data shows that scenes with documented lighting mode rationales consistently outperform scenes without them — not because the documentation improves the lighting, but because the act of articulating the rationale forces the developer to make a deliberate decision rather than accepting a default. The documentation is evidence of deliberateness; the deliberateness is the cause of the quality improvement. This is the lighting pipeline's version of the philosophical practice that the Greek tradition attributed to Socrates: examining one's own assumptions, making explicit what has been implicit, and accepting responsibility for the conclusions that follow.
Closing: The Light That Informs the Scene
The Greek tradition understood light not merely as illumination but as the medium of knowledge. Helios makes the world visible by driving the sun across the sky; Hephaestus captures light in permanent form through the act of making; the liminal space between them is the space in which the highest-stakes decisions about representation are made. The developer who selects a lighting mode in Unity is making a decision in this same space — not about aesthetics, but about the relationship between the scene's illumination and time itself.
Realtime light participates in time. Every frame it exists, it is recomputed. Its cost is the cost of continuous presence. Baked light is outside time. It was produced before the game ran and will not change while the game runs. Its cost was paid at bake time; its runtime cost is zero. Mixed light is the articulation of a boundary between these two temporal regimes — a declaration that some aspects of the scene's illumination belong to the permanent forge and others belong to the moving chariot, and that the boundary between them can be drawn precisely by selecting the Mixed sub-mode that implements the desired behavior.
57 Studios treats lighting mode selection as a first-order architectural decision for every scene in every Unturned mod project. The decision is made before the scene is fully lit, not after. The rationale for each light's mode is documented in the scene's internal review record. Scenes are not considered complete for visual review until every light's mode has been audited against the pre-bake checklist and the post-bake review protocol has been completed. The Yamak Institute's cohort data supports this discipline: scenes developed with explicit mode-selection rationale consistently outperform scenes developed with exploratory defaults, across all experience tiers, across all scene types, and across all visual quality criteria.
The forge produces its best work when the smith knows what he is making before he lights the fire. Helios drives the chariot most effectively when the path is clear and the destination is known. The liminal state is productive when entered deliberately and exited through a committed decision. These are not metaphors for Unity's lighting system. They are descriptions of how the system works — the mythology is the mechanism, stated in terms that make the mechanism's logic legible.