Hi there!
I rarely do lighting work and working to learn a little bit more about it.
I have a scene where I am using some Probuilder objects to assemble some walls and doorways. I’ve noticed that I’m getting some pretty dramatic seams on places where those Probuilder objects are directly beside one another.
These objects have Lightmap Stitching on, but I did also try with it off and didn’t see much difference.
It seems to be anywhere in the scene that two blocks meet, which is mostly above doorways and windows. These rooms are each lit with an area light and the material is a triplanar projection.
It seems to be affecting other pieces that are not Probuilder objects, such as the tops of these lockers:
Any suggestion on settings to fiddle with is appreciated!
When using lightmapping for scenes built out of separate modular meshes you will usually get artifacts like this. It’s a tricky case for a lightmapping, and there isn’t really a silver bullet solution we could add to the lightmapper to solve it.
Really, the only sure-fire way to fix this is to combine the meshes, either via API (Unity - Scripting API: Mesh.CombineMeshes) or via an external tool. I’m not too familiar with probuilder personally, perhaps it has functionality to do this?
You can also try to lessen the seams by cranking the lightmap resolution and sample count really high. It’ll inflate your bake times and lightmap sizes, though. Depending on the desired look you may also be able to hide them with grungy textures or props.
If you are curious, a few of the reasons this happens:
- Since lightmaps are bilinearly filtered, even with 100% converged “perfect” lightmaps, you will usually get harsh seams on mesh borders. The result of bilinear filtering on either side of the seams will be different since you are sampling different texels and with different bilinear weights. This is essentially quantization error. The best you can do to lessen that effect is ensure that the lightmap texel density of every neighboring object matches as closely as possible.
- Texture compression, and in particular block compression, can introduce artifacts like this, since the compression error will be different depending on where in the lightmap a specific object is, and which other texels are nearby. You can disable texture compression or crank lightmap padding up to lessen this.
- Filtering and denoising, applied to the lightmaps as a post-process, can amplify these artifacts. These steps don’t have any way of knowing which meshes are supposed to be considered a single surface, and thus can’t apply filtering across the seams. That often results in slight differences in brightness near the seams. You can disable filtering and denoising entirely, but you will need to use a lot more samples to reach the same visual quality, and bakes will take longer.
If you aren’t too attached to the idea of lightmaps, and you are using URP or HDRP, you could opt for using adaptive probe volumes. They come with a different set of tradeoffs than lightmaps, but should at least not exhibit this issue.
Btw, since you mentioned it: The lightmap seam stitching feature only works for seams between charts within a single mesh, not for seams between different meshes. It lessens the impact of the 1st of the 3 reasons I mentioned in my previous message (and only the 1st), but for seams within a single mesh specifically.
Thanks for the reply, Pema-Malling.
That’s some very useful and interesting information! Disappointing, but understandable that there isn’t an immediate solution!
I spent yesterday bracketing out the resolution and found something that’s not insanely large with decent results. I also tried disabling filtering but that made the scene look… not at all good.
With my current result I think they are manageable, but I am planning to deploy to web, so overall file size is a major limiting factor. Are there any tips to get the filesize more manageable? Currently the size of the lightmap information is approaching twice the size of all textures in the project. The lightmap data appears to be about 315mb for 200 files (including meta files) and the textures in the project are about 180mb for over 2200 files (also including meta files). Any steps I can take to remedy this that don’t reintroduce those artifacts?
Further inspection shows that the large files seem to be the .EXRs, which I guess are high dynamic range image files? Is there any way to request the output files are in another format, such and PNG? Shy of that, is there a process that can take those EXR files, convert them, and then reassign them?
The primary factors that will affect the disk space used by lightmaps are the texture format and the size of the lightmaps. Goes without saying, if you lower the size or count of your lightmaps, you’ll use less space, so format is the more interesting one.
Texture format for lightmaps is determined by a combination of 3 things:
- Your build target (f.x. we choose different formats when targeting mobile).
- Your lightmap encoding quality setting (Project Settings > Player > Other Settings > Lightmap Encoding Quality).
- Your lightmap compression setting (Window > Rendering > Lighting > Lightmap Compression).
With the default settings I believe lightmaps use full HDR on all platforms that support it. That’s by necessity since there is no upper bound on how bright lighting can be. You can use the lightmap encoding quality to mimick HDR with LDR texture formats, at the cost of some visual fidelity. If you use medium quality encoding, for example, Unity will use RGBM encoding which uses an LDR format but stores an exponent in the alpha channel.
Generally speaking:
High encoding quality = HDR format = More disk space used
Medium or low encoding quality = LDR format = Less disk space used
Compression disabled = No block compression = Less disk space used
Compression enabled = Block compression = More disk space used
Finally, depending on the resulting texture format (not all formats support it), you can use crunch compression which can further lower the disk space used. You apply it on the texture importer for the lightmap. I wouldn’t really recommend doing this, though. Crunch can look pretty bad.
1 Like
