Skip to content

Normal Maps & Flat Albedo

Every other page here is about baking a finished image — lighting the prefab in the studio and capturing the result. This page is about the opposite: capturing a sprite without its lighting, plus a normal map, so your game can light it at runtime. A torch sweeping across a wall, a muzzle flash throwing shadows the right way, a character reacting to the lamp they walk under — all of it needs surface information a flat PNG doesn't carry.

Snap can export that information alongside the colour frames, as a second image per capture.

URP only

Normal map and flat albedo export pairs with Unity's 2D dynamic lighting (the URP 2D Renderer), which Built-in and HDRP don't provide. On those pipelines the two toggles appear disabled and forced off, with a note saying so — nothing is silently skipped. See Render Pipeline Notes.

The two toggles

Wherever Snap offers this, it offers both options together:

Toggle What it does
Export Normal Map (URP) Also saves a view-space normal map ({name}_n.png) for dynamic 2D lighting.
Flat Albedo (for normal maps) Renders the colour as a flat unlit albedo — no studio lighting — to pair with the normal map.

The normal map is rendered by temporarily swapping the prefab's materials, reading the surface normals in view space, and encoding them to RGB. The original materials are restored immediately afterwards, so nothing about your prefab or scene is changed by the capture.

Why Flat Albedo matters

This is the part worth reading twice, because it's the mistake that looks fine in the export folder and wrong in the game.

Snap lights your prefab beautifully by default — that's the whole point of the studio rig. But if you export a normal map and keep that studio lighting in the colour frame, you ship a sprite that already has light baked into it, and then your game lights it again. Highlights sit where the studio key light was rather than where the game's torch is, and the result reads as muddy and oddly lit no matter how you tune the scene.

Flat Albedo solves it by rendering the colour pass unlit: flat base colour, no studio lighting at all. It looks wrong on its own — deliberately. It's the raw material for your game's lights to work on.

Snap warns you about this in the panel if you turn one on without the other:

Normal Map without Flat Albedo bakes your studio lighting into the colour, so the game's lights will double-light it. Turn on Flat Albedo for dynamic 2D lighting.

Rule of thumb

Exporting normal maps for dynamic lighting? Turn on both. Exporting a normal map for some other purpose and you want the lit look? Leave Flat Albedo off and ignore the warning — it's guidance, not a block.

Where to find them

The toggles live in the export panels that produce frame sets:

Panel Where
Single Frame Export Animation tab — captures the current pose as a static sprite
Export Selected Clip Animation tab — all frames of the selected clip
All Clips Export Animation tab — every clip on the prefab
Batch Editing & Multi-Prefab Export Batch tab — many prefabs, consistent single-angle capture

Not in Quick Export

The single-sprite Quick Export panel has no normal-map option. For a one-off normal map, use Single Frame Export on the Animation tab, or Batch Editing & Multi-Prefab Export for a single prefab.

What lands on disk

Each colour frame gets one sibling file, named with an _n suffix before the extension:

Hero_Frame_000.png      <- colour (flat albedo, if enabled)
Hero_Frame_000_n.png    <- normal map
Hero_Frame_001.png
Hero_Frame_001_n.png

Both go in the same folder as the colour frames. The normal maps are treated as a deliverable, not scratch — so they survive Skip Raw Frames, which purges the colour frames after a sprite sheet or GIF is assembled but deliberately keeps the normals.

Everything that assembles frames into something else — sprite sheets, GIFs, loop detection, Game-Ready trimming — excludes _n.png files from its input. Your sheet is never doubled or interleaved with normal maps, and your clip never plays a normal map as if it were a frame.

Wiring them up in Unity

Snap gives you the maps; assigning them is a Unity step it doesn't guess for you. In outline:

  1. Import both images. Set the normal map's Texture Type to Sprite (2D and UI) — not "Normal map", which is for 3D tangent-space maps.
  2. Create a material using Universal Render Pipeline/2D/Sprite-Lit-Default.
  3. Assign the colour sprite as the main texture and the _n.png as the Normal Map.
  4. Put the material on your SpriteRenderer, and make sure your scene has 2D lights and the 2D Renderer set on your URP asset.

Exported normal maps but the sprite isn't reacting to lights?

The usual causes, in order of likelihood: the URP asset isn't using the 2D Renderer; the material is Sprite-Unlit rather than Sprite-Lit; the scene has no 2D lights; or the normal map was imported with Texture Type Normal map instead of Sprite.

Game-Ready output

Game-Ready builds its clips and prefab from the colour frames and ignores the _n.png siblings entirely — see Exported normal maps or separated shadows too?.

That's deliberate: the generated prefab uses a plain SpriteRenderer, so swapping it to a Sprite-Lit material and assigning the normals stays your decision. The animation is built for you; the lighting setup isn't assumed.

From script

Both options are available through the headless Capture API as job fields:

var result = SnapCapture.RunStatic(new SnapStaticJob
{
    prefabs         = new[] { "Assets/Characters/Hero.prefab" },
    exportNormalMap = true,
    flatAlbedo      = true,
});

The same two fields work in a JSON job file, and the reported image count accounts for both passes — a job capturing one frame with normal maps on writes two files.