Lightmap switching tool: swap baked lighting in a Unity scene at runtime

The problem: one geometry scene, many lighting looks

The tool is described as allowing switching of different baked lightmap sets on a Unity scene at runtime, and the README states its intent more precisely: switching pre-baked lightmaps, light probes and realtime lighting on a static scene at runtime. The problem it addresses is architectural. A Unity project usually has one scene that holds the level, and a lighting pass that bakes light into that geometry. If a game needs a day look, a night look and a cave look, the common workaround is to duplicate the scene, once per lighting setup, and load between them. That duplication is expensive in memory and in maintenance, because every geometry change has to be applied in each copy. The package's answer is to separate the two concerns: one scene with static geometry, several scenes with only lighting, and a component that loads the right lighting at runtime. The README notes the switch might not be instant but can take some seconds depending on the platform or the content, which is the price for not duplicating the scene.

The LevelLightmapData component holds the scenario list

The system is built around the LevelLightmapData component. The README describes it as the piece that references the different lighting scenes, builds the lighting, and stores the dependencies to the lightmaps. In your static geometry scene you add an empty gameObject and attach this component to it, then fill in the lighting scenarios size with the number of scenarios you want and populate the element fields either by dragging scenes from the Project view or by clicking the small point on the right of the field to pick one. From there the switch is a single call: the public method LoadLightingScenario takes an integer that is the index of the scenario in the list, and the sample project drives it from UI buttons through a UnityEvent. The README is explicit that you call the method yourself, either from a script or through UnityEvents, and that the sample project is only an example of doing that.

A ScriptableObject workflow when the scenarios ship as assets

There is a second, more asset-oriented route, described in the README as the ScriptableObject workflow and illustrated by a scene named GeometrySceneScriptableObj.unity. You right click in the project window and choose Create / Lighting / Lighting Scenario Data, name the asset, then in the inspector type the geometry scene name and the lighting scene name. There is a checkbox for whether to store renderer infos, which the README says is useful only if your lightmap scales and offsets change between scenes. Clicking Generate lighting scenario data produces the asset, and you repeat this for every scenario. In the geometry scene you add a gameobject with the LevelLightmapData script, click Show scenario data, type the number of scenarios, and drag the assets into the slots. LoadLightingScenario then accepts either an integer index into the list of lighting scenario data assets or a string that names the scenario, which is the form you want when the scenario is loaded from an asset bundle.

Installing the package from an OpenUPM scoped registry

The README documents installation for Unity 2020.2 and newer, and it happens through the Package Manager rather than a download. In Unity you open the Project Settings window, select Package Manager, and add a new Scoped Registry that references the openupm registry, https://package.openupm.com. You then add the scope com.laurenth to that Scoped Registry so the package resolves. You then open the Package Manager window, select My Registries in the toolbar, pick Lightmap switcher in the list and click Install. The sample project is imported from the same window, where the package entry has a Samples section with an Example scene line and an Import to Project button, after which ExampleScene.unity opens from the Samples folder. The README notes the package badge points at the openupm page for com.laurenth.lightingtools-lightmapswitcher, and that this version is compatible with Unity 2019.3 and above, with previous releases covering Unity 5.5 to 5.6.

Lighting scenes must be in the build, and auto baking must be off

Two configuration constraints decide whether the system works at all. The first is about the lighting scenes. If a lighting scene contains realtime or mixed lights or reflection probes, the script treats it as necessary to load that lighting scene at runtime so the full lighting can be replicated, and that scene then has to be listed in the Scenes in Build section of the build settings. The second is about baking. The geometry scene should hold static geometry only, auto baking should be disabled, and if you want to use light probes you also add a lightprobe group to that geometry scene. The lighting scenes themselves should not contain static geometry, and their lighting settings must not use auto baking either. The reasoning is visible in the workflow: the tool controls when lighting is built and loaded, so automatic baking would work against it.

Static batching and lightmap scale and offset do not mix

This is the sharpest constraint in the README, and it splits into two cases. If your lighting scenarios use lightmaps of different resolutions, you will probably need to disable static batching in the PlayerSettings, and the README gives the condition under which you can keep it: if you use the same lightmap resolution across all your lighting scenarios and the object packing in the lightmap atlas does not change between them, it is fine to leave static batching enabled. When you do want to keep static batching, the reason is stated separately: lightmap scale and offset cannot be applied at runtime, so you must make sure the lightmap resolutions are the same in all scenarios and disable Apply Lightmap Scale and Offset on the LevelLightmapData component. In other words, static batching is available, but it costs you per-scenario scale and offset. The supported list also has honest gaps: mixed lighting mode is tested only for baked indirect and shadowmask, with shadowmask support credited to a contributor in the README.

No default scenario, and a repository that has not moved in months

The FAQ answers a question many integrations hit: there is no default or fallback lighting scenario. The LevelLightmapData script does not load anything by default, and your scene loads in the state you last saved it in, so you have to call it explicitly from a script or from a UnityEvent in OnEnable or OnAwake if you want a scenario applied at start. That is a deliberate design choice, since it puts you in control of when the switch happens, but it also means a scene that relies on a default will look wrong until you add the call. On maintenance, the repository is not archived and the last push was on 2026-05-31. The recent release tags are older still: 2019.3.3 from 2024-12-08, 2019.4.4 from 2024-09-08 and 2019.4.3 from 2024-08-31, all fix releases. The licence is MIT, with a LICENSE file at the repository root, and the tree is a normal Unity project layout with Assets/, Packages/, ProjectSettings/ and readme.md.

Editorial conclusion

Adopt the lightmap-switching-tool when your Unity project has one static geometry scene and several baked lighting looks, and swapping between them by loading separate scenes would force you to duplicate the geometry. Do not adopt it if you rely on runtime lightmap scale and offset with static batching, since the README says scale and offset cannot be applied at runtime in that case, and do not expect instant transitions, as the switch may take some seconds depending on platform and content. Before wiring it in, decide whether you need the inspector-based workflow or the ScriptableObject workflow for asset bundles, and confirm your lighting scenes are in the Scenes in Build list if they contain realtime lights or reflection probes.

Frequently asked questions

Official sources

1. Issues
2. laurenth-personal/lightmap-switching-tool on GitHub
3. License: MIT
4. README
5. Releases