Last reviewed 26 May 2026

Swap Baked Lightmaps for Day and Night Modes in VRChat

Swapping baked lightmaps lets a VRChat world change between lighting states, such as day and night, without relying on expensive realtime lights. Use Maebbie's video for the Unity demonstration. The notes below focus on VRChat world checks before using the setup in a live project.

Recommended Setup

Build the lightmap swap in a small duplicate scene first, then move the proven setup into the production world once both lighting states are stable.

Back up the world and keep one untouched scene copy.
Bake day and night states with the same static geometry layout.
Test the toggle on PC and Android/Quest before widening visibility.

VRChat note

For Quest and Android worlds, baked lighting is usually the right direction, but every extra lightmap texture increases package size and memory pressure. Keep the lightmap count and resolution intentional.

Playlist Companion

Open the video on YouTube

Creator: Maebbie
Watch on YouTube: Open the Maebbie lightmap swap video on YouTube

Good Fit

Use this page when you want a day/night, emergency-lighting, event-mode, or alternate-atmosphere toggle in a VRChat world, but you do not want to pay the runtime cost of realtime lighting. It works best for creators who already understand basic baked lighting and now need a safer way to manage multiple lighting states.

Before You Start

Confirm you are using the supported VRChat Unity version for the project.
Open the project through VRChat Creator Companion when possible.
Confirm the world already builds and uploads before adding the lightmap swap.
Make a backup or duplicate scene before rebaking lighting.
Decide whether PC and Quest will share the same visual target or use different lightmap budgets.
Check for red Console errors before assuming the lighting workflow is the problem.

Why Swap Baked Lightmaps

Realtime day/night lighting is expensive in VRChat, especially on mobile hardware. Baked lightmap swaps move most of that lighting cost into precomputed textures, then let the world toggle between prepared states.

Good candidates include:

Day and night mode.
Event lighting versus normal lighting.
Emergency or blackout mode.
Seasonal or mood lighting.
Static rooms where the geometry does not change between states.

Poor candidates include scenes where the static geometry changes heavily, where many dynamic objects need believable lighting, or where the extra lightmap memory would push the Quest build over budget.

Planning Checklist

Check	What Good Looks Like	Why It Matters
Static geometry	Day and night bakes use the same baked meshes and UV layout.	Lightmaps are tied to renderer/lightmap data, so mismatched geometry breaks the illusion quickly.
Lighting states	Each state has its own deliberate lighting setup, not a random duplicate.	Clear states are easier to debug and easier for players to understand.
Dynamic objects	Light probes, reflection probes, and dynamic props are considered separately.	Baked lightmaps do not automatically solve avatar and moving-object lighting.
Quest budget	Lightmap resolution and compression are checked for Android filesize and memory.	Extra baked states can make a Quest build too heavy.
Toggle UX	The player-facing toggle has a clear label, cooldown, or owner-only control if needed.	Lighting changes can be disruptive in public worlds.

Core Workflow

Duplicate the scene or create a controlled test scene.
Group the baked static geometry so you can keep day and night versions organized.
Set up the day lighting and bake it.
Store or preserve the day-state renderer/lightmap data.
Set up the night lighting and bake it with the same static geometry layout.
Connect the toggle logic so the world can switch between the prepared states.
Update skybox, reflection probes, emissives, fog, post-processing, or ambient settings to match the selected state.
Build and test the world on the target platform.

PC and Quest Notes

PC can usually tolerate higher resolution lightmaps and more visual polish, but that does not make the workflow free. Quest and Android worlds need a stricter budget:

Keep lightmap resolution lower than your first instinct.
Use fewer lightmap textures where possible.
Avoid duplicating large textures for tiny visual differences.
Prefer baked lighting and light probes over realtime lights.
Test Android package size after adding the second lighting state.
Check the world on actual Quest hardware if the feature is meant for Quest users.

If the Quest version cannot afford the same swap, make the platform difference intentional rather than quietly shipping a broken or oversized Android build.

Follow-Along Checklist

Confirm the scene has a VRC Scene Descriptor when the workflow affects uploadable world content.
Keep the baked geometry consistent between day and night states.
Check light probes and reflection probes so avatars and dynamic props do not look detached from the selected lighting state.
Retest performance, filesize, and memory on the target platform after adding the extra lightmap data.

Help! The lightmap swap works in Unity but not after upload.

Build and test a minimal version in VRChat first. Confirm the toggle object, Udon references, baked renderers, and serialized lightmap data survive upload, then move the same structure into the production scene.

Help! Dynamic props or avatars look wrong after the toggle.

Review light probes, reflection probes, ambient settings, and any realtime fill lights used for dynamic objects. Baked lightmaps mainly affect static renderers, so dynamic objects need their own lighting plan.

Help! The Quest build became too large or slow.

Lower lightmap resolution, reduce the number of affected objects, compress textures carefully, and consider whether Quest needs the full alternate state. Extra baked lighting is still texture data, and mobile builds feel that quickly.

Help! The toggle is confusing for players.

Label the control clearly and decide whether everyone, only instance owners, or only staff should trigger it. A world-wide lighting change can affect comfort, photos, events, and accessibility.

Help! I want to apply this to a production world.

Rebuild the swap in a small copy first, then move only the confirmed geometry, baked data, probes, toggle logic, and visual-state settings into production. Lighting experiments are much easier to discard before they are woven through the main scene.

Final Testing Pass

Before treating the feature as complete, test the world like a player:

Join the world fresh and confirm the default lighting state is correct.
Toggle between states more than once.
Leave and rejoin to confirm the starting state is predictable.
Test with at least one other player if the toggle is networked.
Check mirrors, cameras, video players, avatars, pickups, and interactive props in both states.
Run a PC build and an Android/Quest build if the page title promise applies to both platforms.

Official References

Related Docs

Topics: lightmaps, playlist