Lightmap persistence per scene

2025-10-29 12:09 UTC gpt-5-thinking Open in ChatGPT ↗

Short answer: they’re per-scene, not per-object. Bakery writes the textures to disk and stores the renderer→lightmap indexing/UV scale-offset in a hidden “lightmap storage” object inside your scene (Unity’s LightmapSettings.lightmaps array + Bakery’s !ftraceLightmaps/ftLightmapsStorage). That means you can safely keep multiple lightmap sets for the same scene and swap them without rebaking or cross-contaminating them—so your “Day (indirect GI)” and “Night (AO-only)” won’t affect each other as long as you keep their outputs separate and don’t overwrite the scene’s active set. citeturn1search11turn1search7

How to do your Day/Night setup cleanly

Bake two sets to different folders
- In Bakery, change Output Path before each bake (e.g., Assets/Lightmaps/House_Day/ and Assets/Lightmaps/House_Night/). Bake with your desired lighting each time. This ensures identical UVs but different texture assets. citeturn2search0
Capture the mapping for each set
- After each bake, cache LightmapSettings.lightmaps (and, if used, Light Probes) to your own ScriptableObject or static data. At runtime you’ll just assign the array you want. citeturn2search1
Swap at runtime
- Write a tiny script that assigns the stored LightmapSettings.lightmaps = myDaySet; or myNightSet;. Many example scripts/tools do exactly this. citeturn0search22turn2search23

Baking specifics for your two looks

Day = “bake indirect GI”
Use Mixed/Indirect modes so only indirect from your lights is baked; keep realtime direct for the sun/lamps. (In Bakery, lights have Baked contribution and Indirect only options.) citeturn3search0
Night = “AO-only” look
Disable/zero out direct lights and bake with Ambient Occlusion enabled so you capture just contact shadows/occlusion in the map. (Unity/lighting forums + Bakery docs describe AO-only/indirect-only workflows.) citeturn3search1turn3search3

Gotchas to avoid

Don’t let Unity overwrite Bakery results: keep Auto Generate off and don’t hit Unity’s Generate Lighting; use Bakery’s bake buttons only. citeturn1search9
Name/path collisions: different output folders (or Lightmap Group names) prevent one bake from replacing the other’s textures. citeturn2search0
Remember probes: if you rely on Light Probes, store/swap those alongside the lightmap array for each lighting scenario. Many switcher examples include probes. citeturn2search23

If you want, I can sketch a minimal LightmapSwitcher script you can drop into your scene to toggle Day/Night.

Yep—duplicating the scene is the simplest, cleanest way.

Lightmaps (and their renderer → lightmap indices/scale-offsets) are stored with the scene, so if you make two copies—e.g., House_Day.unity and House_Night.unity—each scene can keep its own bake with no runtime swapping logic.

Do it this way

Duplicate the scene → House_Day and House_Night.
Open House_Day
- Set up your “indirect GI” lighting.
- In Bakery, set a unique Output Path (e.g., Assets/Lightmaps/House_Day/).
- Bake.
Open House_Night
- Turn off direct lights / set AO-only look.
- Set a different Output Path (e.g., Assets/Lightmaps/House_Night/).
- Bake.

That’s it—each scene now references its own lightmap textures and mapping.

Important gotchas

Unique output folders are key. If both scenes write to the same folder, a later bake can overwrite textures the other scene uses.
Keep Unity’s Auto Generate off (use Bakery’s bake buttons only), so Unity doesn’t regenerate lighting and clobber Bakery’s results.
Probes & reflection probes are also per scene—just bake them in each scene as needed.
Additive loading case (optional): If you ever load both scenes at once, Unity merges their lightmap arrays at runtime. This is fine; just keep separate outputs so nothing gets overwritten on disk.

Since you’re okay with two scenes, you can skip any lightmap swapping scripts entirely.

That warning is Unity/Bakery telling you: “I can’t bake this renderer because the mesh I see doesn’t have what I need (normals/UVs/etc).” It’s not literally “because it’s animated,” but animated/movable things often end up in a state where Bakery can’t or shouldn’t bake them.

Here’s what’s going on and what you can do.

1. Can you lightmap an opening door?

Practically: no, not in the normal “static lightmap” way. A lightmap is world-space lighting frozen to a UV on the mesh. If the door rotates, the baked shadows/highlights stay stuck to its surface, so as it opens it will look wrong (the lit side won’t change, and the door won’t cast a changing shadow).

Standard workflow: make the door non-static and let it use Light Probes (or Bakery’s probes). That’s how doors are usually handled.

2. Why that specific error?

You usually see that message when:

The renderer is something Bakery doesn’t want to bake (e.g. a SkinnedMeshRenderer), or
The imported mesh has no UV2 / lightmap UVs or normals.

Animated doors often use a skinned mesh or a special mesh that wasn’t imported with lightmap UVs, so Bakery says “can’t generate lighting for this mesh.”

Check this:

Select the door model asset in Project → Model Import Settings:
- ✅ Read/Write Enabled
- ✅ Generate Lightmap UVs
- Normals: Import or Calculate
- Apply
Make sure the object in the scene is a MeshRenderer, not only a SkinnedMeshRenderer. Bakery is happiest with a plain MeshRenderer.

If you fix the import and make it a plain MeshRenderer, Bakery will probably bake it — but see point 1: it still won’t look right once the door moves.

3. So what are your options?

Option A (recommended): use probes

Keep the door not Static.
Bake the scene normally.
Put light probes near the door (or use Bakery’s probe system).
The door will pick up baked lighting that moves with it. No error, and it looks correct enough for a moving prop.

Option B: bake it in the closed position only

Temporarily mark the door static / fix its mesh so Bakery can bake it.
Bake.
Then uncheck Static again and animate it.
Result: the door will keep the baked texture but will look “wrong” when open (shading doesn’t change). Sometimes that’s acceptable for small motions.

Option C: vertex/SH baking (if you really want baked lighting on an animated mesh)

Bakery has ways to bake lighting to probes / per-vertex data that can be sampled by moving objects. That’s meant exactly for “animated/dynamic but I still want baked-like light.”

So: yes, the fact that it’s a moving door is the real problem (conceptually), and the error is Unity/Bakery’s way of telling you this particular mesh isn’t in a bakeable state. Easiest fix: make the door dynamic and light it with probes.

Totally doable 👍

What you want is: “bake as if the door is closed,” but use an animated/non-bakeable door at runtime. Easiest way is to separate “bake blocker” from “game door.”

Here are a few ways to do it.

1. Bake-only door (recommended)

Duplicate the door (or make a simple box the size of the closed door).
Put that copy in the closed position.
Mark that copy Static / Contribute GI so Bakery uses it.
Bake.
After the bake, disable that bake-only door (or put it on a non-rendered layer).
Keep your real/animated door non-static and lit by light probes.

Result: the lightmap is computed with the door closed (so no extra light leaks), but the player still sees/uses the animated door.

Why this works: once the lightmap is baked, Unity/Bakery doesn’t “un-bake” those occlusion/shadows just because you hid the object.

2. Fix the actual door, bake once, then un-static it

If you really want to bake the real mesh:

Fix the import on the door mesh so it has normals + lightmap UVs (Model → Generate Lightmap UVs).
Mark it static and bake with the door closed.
Then uncheck Static again so you can animate it.

Same result: lighting stays “door closed.” Downside: when the door opens, its own baked shading will look wrong (because it was baked closed).

3. Use a super-simple blocker

If the real door is skinned / weird / still errors:

Just drop in a thin cube exactly where the closed door would be.
Make it static.
Bake.
Hide/delete the cube after baking.

That’s the lowest-friction version.

Extra notes

This won’t “burn the whole scene” with light anymore because the closed-door blocker stops the GI during the bake.
Keep Auto Generate (Unity) off and use Bakery’s bake.
Make sure your animated door uses probes so it isn’t pitch black.

So: don’t fight the animated door mesh — just give Bakery a closed, bake-only door to occlude the light, then hide it.

You don’t have to split the FBX into 3 separate meshes just to get 3 materials — one mesh can have multiple materials, and Unity will import that as multiple submeshes.

Here’s the usual way people do it 👇

Option 1 (most common): assign multiple materials in Blender

Open the mesh in Edit Mode.
In the Material tab, add 3 material slots: Body, Clothes, Hair.
Select the faces that belong to (say) the hair → click Assign on the Hair slot.
Do the same for clothes and body.

Export FBX → Unity.
Unity will show one SkinnedMeshRenderer/MeshRenderer with 3 material slots. You can drop 3 different Unity materials there. Done.

When to unwrap?

If each part will use its own texture, you still need UVs for those faces. Often the original FBX already has UVs; you can just reuse them.
If the UVs are a mess or overlapping in a way you don’t like, yes, unwrap in Blender (per-part or whole mesh). That’s normal.

So UV unwrapping isn’t the thing that gives you multiple materials — it just makes sure each part can be textured nicely.

Option 2: physically split the mesh

In Edit Mode: select hair faces → P → Selection → becomes a separate object.
Do the same for clothes.
Export. Unity will import 3 renderers (or 3 skinned parts if you keep the armature).
This is fine, but more objects = slightly more drawcalls / management. People do this when the parts need to be toggled (hide hair, swap outfit) or have very different shaders.

Which is “more efficient”?

Single mesh, multiple material slots → simplest, common in character FBXs, good for Unity. Unity creates submeshes; 3 materials = 3 draw calls, which is expected.
Separate objects → better if you want to enable/disable/swaps at runtime.
One material / texture atlas → most performant, but more work: you’d unwrap everything into one UV space and paint a single texture. Then only 1 drawcall. This is what mobile/optimized projects do.

TL;DR for your case

No, you don’t have to unwrap just to separate hair/body/clothes.
Do this: select faces → assign to different materials in Blender → export → assign materials in Unity.
Unwrap/clean UVs only if the current UVs don’t suit the textures you want to paint.

Right — if your render features key off layers on GameObjects, then “one mesh with 3 material slots” won’t help, because Unity’s renderer feature will see one renderer on one layer and will draw the whole thing in that pass. Submeshes don’t get their own layers.

So for your setup you need separate renderers / separate GameObjects (each on its own layer).

Here’s the clean way to do it:

What to do

In Blender
- Go to Edit Mode on the character mesh.
- Select the hair faces → P → Selection.
- Select the clothes faces → P → Selection.
- Now you have 3 mesh objects: Body, Clothes, Hair.
- Each of them should still have the Armature modifier (Blender keeps vertex groups when you separate).
Export FBX with the armature + all 3 meshes.
In Unity
- You’ll get 1 skeleton + 3 SkinnedMeshRenderers (children).
- Put Hair GO on Hair layer, Clothes on Clothes layer, etc.
- Your render features can now target each layer separately.

That’s the standard character workflow when people want to:

toggle clothes/hair,
or render outlines separately,
or do x-ray on just the body,
or, like you, run custom passes per part.

Is UV unwrapping still needed?

Only if the textures need new/clean UVs. Separating objects doesn’t magically fix UVs — it just gives you 3 renderers you can put on 3 layers. If the source UVs are fine, you can keep them as-is.

Alternatives (Unity-side)

You can also make editor-time copies of the mesh and strip to one submesh per copy, then have 3 SkinnedMeshRenderers that all use the same bones. People do this with little editor scripts. But since you already have Blender, splitting there is simpler and more portable.

So: yes, option 1 won’t work with layer-based passes — split it into 3 renderers.