The Lightmapper bakes HDR global illumination lightmaps through Cycles

Cycles does the bake, so the cost sits on your GPU or CPU

The Lightmapper is a Blender addon for global illumination texture baking with support for 32-bit HDR lightmaps. The important architectural detail is that the bake is not performed by Blender's own lightmapper. The project states that baking is done through Cycles, which means the render engine you already configure for final frames is also the engine that computes the lightmap. The addon layer sits on top and handles the parts a render engineer would otherwise script by hand: scaling, material setup, UV layering, UV unwrapping, encoding options, format options and postprocess filtering.

That division shapes who benefits. A technical artist who wants a single baked irradiance texture for a level that will be shipped into a game engine, or a small HTML or Armory scene, gets the heavy lifting automated. A studio with a large in-house pipeline probably already has its own bake scripts, and the addon's value there is mostly the preset layer and the denoiser choices. The setup is object-centric, which is the phrase the project itself uses. Settings such as resolution, UV margin and unwrap mode are customized per individual object rather than globally, so a single scene can hold a high resolution map on a hero prop and a coarse one on background clutter.

Multi-material support is bundled in. You can add as many materials to each object as you want, and the project also describes resetting materials easily and baking without material setup entirely for external engines, which is useful when the target renderer expects its own material convention rather than a baked map.

Per-object resolution, UV margin and unwrap mode live in the object properties

The addon's user interface splits into two entry points. To enable lightmapping for a single object you go to object properties and open the The Lightmapper tab, then enable it. To cover the whole scene you open Utilities and click "Enable for set", and by default that applies to all objects in the scene. Everything else is tuned from the same per-object panel.

Three parameters appear on that panel: resolution, UV margin and unwrap mode. Resolution decides how large the resulting lightmap texture is for that object. UV margin controls the padding around each island, which matters because a lightmap sampled across a UV seam can bleed from the neighbouring texel and produce a visible dark or bright edge. Unwrap mode decides how the addon lays out the islands, and the project lists Blender xatlas by Mattedicksoncom as a third party addon for that purpose, alongside OpenCV from PyPI. The presence of xatlas in the dependency notes suggests the addon expects an external unwrapper for at least some of its modes rather than implementing its own atlas packer.

That is the practical detail to check before a large bake. If xatlas is missing, the unwrap options that depend on it will not behave as the panel implies, and you will find out halfway through a batch rather than at setup time. Nothing in the write up states a fallback path for a missing xatlas install, so treat it as a hard prerequisite rather than an optional extra.

Denoising has three paths and they are not equivalent

The addon bundles denoising directly into the bake. Three options are described: integrated denoising, faster CPU OIDN denoising, and GPU Optix denoising. Denoising matters here because a low sample bake is fast but noisy, and noise in a lightmap is not something you can fix later with a denoiser pass in your image editor, since the noise has been resampled across the UV layout and baked into the texture.

The three paths differ in where the work runs and in what hardware they assume. Optix requires an NVIDIA GPU with the matching acceleration stack available, so that path is unavailable on other vendors or on headless render nodes without the driver. OIDN on CPU is the portable option and is described as faster than the integrated route. On a farm with plenty of memory bandwidth per core, CPU OIDN is a reasonable default; on a workstation with an Optix capable card, the GPU path is the one that keeps bake times down.

Do not expect the three to produce identical maps. Denoising is a reconstruction, not a lossless cleanup, and the artefacts it introduces vary by implementation. The write up claims denoising and quality together but publishes no side by side image or timing table for the three options, so the only reliable way to choose is to bake the same object twice with the denoiser changed and compare. That comparison is cheap on a single prop and expensive to do after a full scene bake.

OpenCV filtering runs after the bake and can cover up bad unwraps

Beyond denoising, the project adds a postprocess stage described as additional filtering to give lightmaps an extra edge and quality through OpenCV. The OpenCV dependency is listed as a third party addon compatibility item, pointing at the opencv-python package on PyPI. Filtering at this stage is a genuine advantage of using an external library rather than a native Blender operator, since the library brings a set of classical image operations that Blender's bundled filters do not expose.

It is also a place where a user can quietly ruin a map. Any postprocess that blurs or resamples a lightmap reduces precision in the very gradients that carry the lighting. A lightmap that looked correct when denoised can gain soft halos around light sources after a pass that is too aggressive, and 32-bit HDR storage does not rescue it because the blur happens in the same precision domain. The write up does not document which filters are exposed, what their defaults are, or whether the stage can be switched off entirely, so treat the postprocess as something you should evaluate visually on a test object rather than as a background detail.

The 32-bit HDR capability is the reason this project is worth the setup effort at all. A lightmap stored as an 8-bit texture clamps values, and bright windows, emissive strips and sunlit surfaces lose the range that makes a baked result look plausible next to the original scene.

Background baking needs a saved scene and frees the interface

Baking a scene at usable resolution takes long enough to block an artist, so the project offers background baking, described as letting you continue working on your scene while the bake runs. There is one precondition that the write up states plainly: to lightmap, the scene needs to be saved to disk. That is a hard requirement, not a suggestion, so an unsaved file cannot be baked even in the foreground path.

The saved-scene requirement has a practical consequence. Background baking means the bake reads the file from disk, so any edits you make to the scene after starting the job are not part of what gets baked. If you continue working, you need to save a new version and understand which one the running job picked up. The write up does not explain how a background job resolves the file state at launch, so the safe pattern is to save, start the bake, and treat the file as frozen for the duration.

Presets also shape the speed tradeoff. Baking presets automatically adjust sampling, quality and tile settings based on situation and whether the machine is on CPU or GPU. That is convenient, and it also means the effective sample count of a given bake is not something you read directly from a panel, it is the preset's choice given your hardware and scene. When you compare two bakes for quality, pin the preset and the denoiser first, otherwise you are comparing the preset's guess as much as your settings.

Installation is a release zip, and the wiki linked from the README does not exist yet

The installation path is short: download the latest release and install it as a .zip file from inside Blender. That is the whole procedure the project documents. There is no pip install line, no Blender extension marketplace entry described, and no version pinning guidance in the write up, so the exact command sequence lives outside this document and cannot be reproduced here.

The gap is documentation. Two separate pointers in the write up, one under Installation and one under Usage, both refer to a wiki section marked COMING SOON, and the Documentation section says the wiki page is under construction and documentation is in the process of being written. In practice that means the workflow, the panel semantics and the postprocess options are described by a feature bullet list and a set of screenshots rather than by reference material. Anyone adopting this addon should expect to learn the parameter behaviour by experimenting, and should budget time for that.

The repository layout is small: LICENSE, README.md, __init__.py, an addon directory and an img directory. The addon directory holds the code, and the images are the screenshots and example renders that the feature list relies on. The example gallery in the write up points at a laboratory site with HTML5 lightmap examples powered by Armory3D, which is a reasonable place to see what a finished map looks like before you commit to the setup.

GPL-3.0 terms and a release trail that trails the last commit

The project is licensed under GPL-3.0. For a Blender addon distributed to artists inside an existing toolchain, that matters for how the code can be redistributed and modified, and it is worth having someone familiar with the licence terms read how you intend to embed or bundle it. This is not legal advice, it is a flag that the licence has conditions rather than being a permissive placeholder.

On the release side, the picture is uneven. Tagged releases include 0.7.0 on 2024-10-08, 0.6.3 on 2022-03-22 and a work in progress 0.6.12 on 2022-02-19. The last push to the repository was on 2026-09-24, which is recent, so the code is receiving commits. Those commits have not produced a new tag since 0.7.0, and the feature list in the write up is still headed "Features - Version 0.3", which is older than any of the released numbers. The gap between what the releases are called and what the documentation describes is itself a signal: if you are evaluating this addon for a production pipeline, find out what the tagged 0.7.0 actually contains versus what master contains now, rather than assuming the latest commit is what the release notes describe.

Editorial conclusion

The Lightmapper is a reasonable pick for artists who need to hand a static scene to an engine without runtime GI, and for anyone who wants Cycles to drive the bake instead of the built-in lightmapper. It is a poor fit for real-time workflows that need re-baking on every edit, and for teams that require a documented, versioned release cycle, since the newest tagged release is 0.7.0 from 2024-10-08 and the documentation wiki is still marked as coming soon. Before adopting, check that your Blender and Cycles versions match the addon's expectations, confirm that the OpenCV and xatlas dependencies are present, and bake one test object with background baking off to see whether the denoiser and filter settings produce a map you can live with.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Naxela/The_Lightmapper on GitHub
4. README
5. Releases