Difference between revisions of "Legacy:Lightmap Errors"

Latest revision as of 21:23, 21 May 2010

Zebra Stripes[edit]

On occasion, the lighting compiler will do some funky math and make the lightmaps too small for the face they are being applied to. The effect is a rather ugly "zebra stripe" effect on surfaces as the lightmap repeats itself many times over the face of the object.

There are a few ways to fix this so that you don't have to rebuild the map.

ZoneInfo[edit]

1. put a ZoneInfo in the area in question
2. increase the zone's ambient lighting
3. Rebuild the geometry and lighting
4. If you didn't want ambient lighting there, you can always
   • remove the ZoneInfo
   • set its Zone lighting to zero

Manually move geometry[edit]

1. vertex edit the points of the surface to one position
   • Re-aligns the texture and clears the lighting.
   • Doesn't work as often
   • tends to be hard to implement in large or complex areas.

Other Tricks[edit]

• Restart UnrealED and rebuild the lighting
• Turn off the 3D viewport and rebuild lighting

Avoid the problem[edit]

• wait on lighting an area until you are nearly done with the architecture
• if you want to see the lighting before you finish
  1. save a copy of the map to some other name
  2. apply lighting.

Reduce your test lighting time by adding the lights to a single group in the group browser.

Unlit Surfaces[edit]

Whole Zone(s)[edit]

If you have any ZoneInfo actors with bClearToFogColor set to true, and then rebuild the lightning, all the surfaces in the affected zone(s) will be unlit, not in the sense that the surface is fully bright but that the surface won't have any light on it at all. To remedy the situation, set bClearToFogColor to false, rebuild the lighting, then go back and change the affected zones back to normal.

Random Surfaces[edit]

There are some occasions when one (or few adjacent coplanar) surfaces got unlit randomly and there is no proper way how to fix it. You can move brushes sometimes, recreate it, but when nothing helps (or you don't want to move brushes), simply check screwed surfaces as Two Sided. That workes in most cases (after rebuild of course).

Black Surfaces[edit]

You notice that one surface of subtractive space becomes black--that is, the surface DOES NOT become Unlit (bright).

It has been observed that a Zone Portal sheet was involved with this issue. The offending Zone Portal sheet was observed to be perpendicular to the side of the subtracted space(s) affected, where the Y location was close to that of the affected subtractive brush, and the X location was the same. The Zone Portal sheet in question had a Z location higher in space.

The solution was to displace the Zone Portal sheet by as a little as one unreal unit (UU) on the X position. The lighting error could then consistently be reproduced by moving the Zone Portal sheet back to its original X position.

Moving Zone Portal sheets is perhaps the easiest solution, if applicable, rather than affecting the architecture of the map, or having the engine render two sides of a surface, for instance.

rejecht: Can anyone verify that this solves this issue with their problem maps? I'll see if I can add a picture example.

Linux Lightmap Errors[edit]

Linux is minor gaming platform, so you can omit this when you considering lightmap issues. Problem relates to RGB8 lightmap. Ugly bright partial circles appears in certain distance from light sources and thay look really bad. There is NO problem on Windows client thou and no problem when using DXT3 either (DXT1 is not recommanded elsewhere). Still it appears that RGB8 is best in quality and with compression (that is used in case of lightmaps) is also smaller than DXT3. Problem was discovered on both nVidia and ATI cards, so it looks like it is not related to card, but to some lightmap processing in Linux client (valid for 3369).

Here's the picture from Linux client (map DM-Getherto):

[1]

Related Topics[edit]

• Lighting
• Texture Topics