When importing objects as fbx from Blender, the lightmap uvs are not used when building lighting.
export meshes from Blender as fbx with uvs for material and uvs for lightmap
import in Unreal, ‘generate lightmap uvs’ unchecked
edit mesh - LOD0 - change ‘min lightmap resolution’, change ‘source lightmap index’ to 1. Change ‘lightmap resolution’ under ‘Static Mesh Settings’ as well.
In editor, the custom UV layout for the lightmap in UV channel 1 is visible
build lighting (object is static mesh) - takes a bit more time as usual and ‘Map check found some issues’ → Object has wrapping UVs → strange repeating shadow patterns on object.
Strange shadow pattern on the objects seem to be the same as when having the editor create the lightmap instead.
Make sure that you’ve set the correct lightmap coordinate index in the Static Mesh Editor in the Details panel under Static Mesh Settings > Lightmap Coordinate index.
When you import your own lightmap the editor does not automatically set this to 1 or whatever UV you have for your lightmap since it cannot determine if this is the one you want to use. This is left up to the responsibility of the user to set for their static meshes.
So, while you can see the UV you setup for the lightmap in the UV dropdown and can visualize it in the viewport, you have to set it before it will be used by the engine for light builds.
If this is not the same issue please post back with the following details:
Picture of your current diffuse, lightmap UVs.
Picture of the Lightmap Coordinate Index set to 1 or whatever the UV is for the lightmap.
It works to my surprise because I have never used the Lightmap Coordinate Index before. For the last year (from 4.7 - 4.12) I changed the Source Lightmap Index to 1 and that just worked fine.
Anyway, thanks for the help and solution!
Actually, your assumption here is incorrect. The options you list as 4.7-4.12 were actually added in 4.5 as a new process for generating the lightmap UVs automatically when needed from the Build Settings.
This is something I want to get over into Documentation to make it clear since it is often a confusion from some.
The Build Settings allow you to specify how you want to generate the Lightmap by enabling the option for Generate Lightmap UV and then you can specify the source UV that the lightmap will be generated from. The target UV slot that you want the lightmap UV to be assigned to. You can even set the target resolution, but all that said, none of this actually Assigns or sets the resolution of the Lightmap to that! You will still have to set this under the Static Mesh Settings where these settings for the Lightmap Resolution and Lightmap Coordinate Index actually assign and use these values.
Regardless of all of this, this process has not changed in over two years since this was changed to be more streamlined.
The only real difference here when you create your own lightmaps is that on Import you uncheck Generate Lightmap UV and then in the Static Mesh Editor you need to manually assign and set the lightmap resolution you want.
We just updated one of our 4.12 projects to 4.13, and we came across the same problem as OP. In 4.12, the lightmap channel would be automatically set to 1 (if it existed). Now however, it is set to 0 by default, and as you pointed out the user has to manually set the lightmap channel in the static mesh editor.
The problem with this approach is that is not feasible in large projects. In our current project, we have hundreds of imported meshes. To go through all of these meshes manually would take several hours. To make matters worse, every time we reimport a mesh, the lightmap channel is reset back to 0 (at least when using the import button, not when using right click>reimport).
How do we solve this problem then? I would prefer a project/world/import setting where we could set the default lightmap channel. At the very least, I would expect the lightmap channel setting to be remembered after importing a mesh again.
I submitted a ticket for the initial import not setting the lightmap to coordinate index 1 since that was either a deliberate change I’m not aware of or it was just a regression in behavior from another change. You can follow the status here: Unreal Engine Issues and Bug Tracker (UE-35627)
Hello i have a question: so i went to Unreal Engine Issues and Bug Tracker (UE-35627) and it says this bug is FIXED. Does it mean it is actually already fixed? or we still have to wait until a later release?
