The topic of lightmaps sucking and issues with using them in UE4 has come up. I’d like to address some of the issues as they exist in UE4 today.
The first is the pain of generating your own unique UVs. We have currently have in engine (only on windows due to relying on D3D) 2 methods to auto generate lightmap UVs. The first creates UVs purely from raw triangles, knowing only about vertex positions. The results are pretty poor because seams will show up in random places and the lightmap texels will be arbitrarily aligned. The second method uses an existing UV set and repacks it to be unique. This means lightmap seams will only exist where there are already texture seams, which artists will place intelligently. There are still problems with texel alignment, distribution of area, many small charts, etc.
I just checked in a replacement for the second method yesterday. This is our code so it runs on all platforms. It will repack an existing UV set but much better than the prior method. It won’t rotate charts randomly so the texel alignment will match what the original UVs had. It distributes UV space according to surface area so the lightmap texels will be uniform in size. It will merge UV charts where it can meaning less tiny charts wasting space. In many cases the packing is better than artist provided UVs. It does all this in far less time too. It isn’t perfect but it is **** good.
The next step, which I’m working on now, is to make this an automatic part of the mesh import and building pipeline. By default meshes brought into the engine will use this to generate lightmap UVs. If you have already created some you can specify which channel they are. You can also decide they aren’t needed, in the case of a mesh that is never placed statically. This should prevent the situation mentioned where the lightmap process isn’t understood by the artist early on and tons of stuff needs to be touched later. Instead, if the artist isn’t aware, everything will already have auto lightmap UVs generated and things just work. If fine tuning needs to be done it is much better to start from a working case than a nonworking one.
This auto lightmap UV work is step 1 in my vision for a making the static GI solution a black box. Ideally, the details of how precomputed lighting is generated and stored won’t need to be understood by anyone but the most advanced users. We do a pretty good job in some areas compared to other offline renderers. For instance, the user of lightmass doesn’t need to know anything about the fact that we use photon maps and irradiance cached final gather to calculate GI. Many offline GI solvers expose that and a ton of confusing parameters associated with it. I’d like the same to be true for lightmaps. To use lightmass you shouldn’t need to even know what lightmaps or lightmap UVs are. Most importantly, the fact that lightmaps are 2d textures mapped to surfaces shouldn’t be important to know. Any sort of GI solution that isn’t per pixel will have a resolution so artifacts related to the resolution GI is calculated at can never be completely solved but I feel the artifacts specific to 2d textures can.
Concisely, the vision is that a user should be able to just drop some random models in a level, click build and it just works.
The next steps for achieving this vision:
- Smooth texel mismatch seams using least squares fitting. This trades a minor amount of blurring for making texture seams practically vanish everywhere. http://miciwan.com/SIGGRAPH2013/Lighting%20Technology%20of%20The%20Last%20Of%20Us.pdf
- Lighting needs to exactly match on flat neighboring meshes. Unfortunately, due to the use of irradiance caching and the fact that we distribute the work amongst many machines this is hard to do. Meshes right now are computed completely separately, sometimes on different machines. Making sure the lighting matches across the edges of two placed models in the world without shooting 100s of rays for every lightmap texel is very hard. There isn’t a straightforward solution here but I’m sure there’s something we can do to fix this.
- Lastly there is the potential to leak between UV charts that are packed near one another due to filtering. Some of this comes from sloppy handling of UV packing which we can be much stricter on.
Everything won’t be fixed immediately, but trust me, we are aware of the issues and intend to improve things dramatically.
Lightmaps aren’t some ancient obsolete concept. Some of the best looking games around continue to use them for good reason. There is no more efficient way to map high resolution color data to surfaces than 2d textures. This is true both for memory and performance. If a reduction of one or both is acceptable other options become viable but there is simply no better way to get low cost, very high quality, indirect lighting.