4.7.2: Weird lighting after build (lightmaps uv overlapping)

Hi there,

I tried to import this FBX file: 2009 nissan fairladyz 3d ma (highly-detailed, approx. 3 M vertices)

I checked the option to automically unwrap UV lightmaps. [Documentation][1] says

If enabled, the importer will generate a set of unique, non-overlapping, UVs for use with static lighting.

After 10 minutes of waiting (Haswell, 3.6 GHz) I got a first message:

370 has degenerate tangent bases which will result in incorrect shading. (er, ok…?)

A few minutes later, I could place the object into the scene (seems that all materials are broken):

Next I tried to rebuild lighting which results in this:

(Error coloring is active)

Currently, the UV map of the mesh looks like this:

I am no expert, but that looks kind of broken to me…

I tried the last hours to fix this, but I am not very experienced in 3D modeling. There seems to be an option to “generate unique UV” in older engine versions but it’s not available any more (didn’t that happen on import anyway?)

Is there any easy way to get the lighting working? And do I really have to fully recreate all materials in UE4? What is the best way to import FBX models to UE4 and avoiding such problems?

I tried other models from different authors as well, but I got the same problem with all of them.

Engine Version: 4.7.2

Many thanks.

Update:

  • unwrapped lightmaps manually in 3DS Max 2015
  • selected UV channel 1 in UE4 mesh editor
  • recomputed normals and tangents
  • selected source and target lightmap index to 1
  • set lightmap resolution from 64 to 256 (there is another setting in ‘static mesh settings’, what is the difference to the one in the build settings?)

http://i.imgur.com/iYd1YiU.png

  • applied changes (editor was unusable for about 10 minutes)
  • rebuilt lighting (waiting…)

Same problem:

http://i.imgur.com/P0aWMhM.jpg

Next try: Created a new UV channel (2) in the mesh editor:

http://i.imgur.com/pAQExi9.png

  • Set the newly created channel as 'lightmap coordinate index"

http://i.imgur.com/wsAKgeN.png

  • Rebuilt lighting

→ Still got overlapping UV lightmaps (just with lower percentage than before). Looks still horribly broken:

http://i.imgur.com/kZ6y3Dh.png

I tried several FBX models now, from different authors and not a single one is just working as expected in UE4. Could they really all be broken in so many ways?

Could fully dynamic lighting or vertex lighting (?) be the solution (there will not be much complex geometry in the scene besides this car)?

Is there any reliable way to get rid of this error (hopefully without expert knowledge in 3D modeling)?

Hi Spyro,

I checked the option to automically
unwrap UV lightmaps. Documentation
says

“If enabled, the importer will generate
a set of unique, non-overlapping, UVs
for use with static lighting.”

This is partly true. It the mesh has not had its seams split and flattened in a modeling application this will still generate overlapping UVs. For example, if you have a cylinder that is not unwrapped and flattened in the modeling program UE4 will not split or cut these seams to flatten it. This can still generate overlapping UV errors.

However, I don’t believe this is the issue that you’re seeing.

The settings that you’re showing above are not exactly right. For 1 the lightmap UV should be set to 1 and the source 0. 0 is the diffuse UV where the lightmap will be channel 1 by default.

The settings that are being adjusted are just build setup settings. These do not actually assign or control the lightmap or its resolution.

Once you’ve hit “apply” you will need to go to the tab labeled “Static Mesh Settings” and set the lightmap coordinate index to 1 (or whatever the lightmap channel will be with no overlapping UVs) and then adjust the lightmap resolution to the desired value (power of two: 16, 32, 64, 128, etc).

You can read about this in our Wiki Lighting Troubleshooting and Tips guide.

Could fully dynamic lighting or vertex
lighting (?) be the solution (there
will not be much complex geometry in
the scene besides this car)?

Using a dynamic lighting solution will not require lightmap UVs and will get rid of the error. There may be other issues that you encounter with dynamic lighting that needs to be adjusted for better results though. This can also be found in our lighting guide.

I hope this helps.

Hi Tim,

thanks for your answer. I tried to create lightmaps within UE4 now and assigned it as you suggested (see my first comment). Unfortunately this didn’t solve my problem (tried with another, less complex model here):

http://i.imgur.com/ai5svuz.png

(rebuilt lighting)

http://i.imgur.com/P9FCl7r.png

http://i.imgur.com/lMQdwAU.png

Still broken :frowning:

Any meshes taken from services like TurboSquid are more than likely not going to be “game-ready” and will need some extra attention given in a modeling application.

If you’re getting the overlapping UV error you will need to take a look at the UVs inside a modeling programs UV editor. In 3Ds Max there is the option to check the UV for overlapping faces. I’m not completely sure about other programs.

As I had mentioned, the generated LMs work pretty well, but it requires the UVs to have been setup in a specific way to begin. For most objects this isn’t a problem, but for others it can be.

Ok, thank you. So I’ll guess a have to dive into the horrors of manual lightmap UVW unwrapping in 3DS Max…

But there seems to be another problem with the lightmap UV creation in UE4:

Sometimes it seems not even possible to create a lightmap channel. Although the option was ticked in the FBX import dialog, there is no UV channel 1. So I tried to create the channel manually:

http://i.imgur.com/ntjThqF.png

(Hit apply)

After a few minutes of waiting the operation ended but there is still only one channel available:

http://i.imgur.com/KiIrTCS.png

Lightmap coordinate index is still on 0 therefore.

This feature was only added a few builds ago and still has some known issues. If I recall correctly I think this was one. I believe it was a mesh specific thing with more complex meshes though.