Once I get that upgrade to 36-hour days, I will tackle that. – Mychaeel
Difference between revisions of "Legacy:Lightmap Errors"
(*Lightmap Errors) |
(→Unlit Surfaces) |
||
(One intermediate revision by one other user not shown) | |||
Line 10: | Line 10: | ||
# Rebuild the geometry and lighting | # Rebuild the geometry and lighting | ||
# If you didn't want ambient lighting there, you can always | # If you didn't want ambient lighting there, you can always | ||
− | #* remove the [[Legacy:ZoneInfo|ZoneInfo] | + | #* remove the [[Legacy:ZoneInfo|ZoneInfo]] |
#* set its Zone lighting to zero | #* set its Zone lighting to zero | ||
Line 40: | Line 40: | ||
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). | 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== | ||
+ | |||
+ | 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== | ==Linux Lightmap Errors== |
Revision as of 19:08, 25 November 2008
Contents
Zebra Stripes
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
- put a ZoneInfo in the area in question
- increase the zone's ambient lighting
- Rebuild the geometry and lighting
- If you didn't want ambient lighting there, you can always
- remove the ZoneInfo
- set its Zone lighting to zero
Manually move geometry
- 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
- Restart UnrealED and rebuild the lighting
- Turn off the 3D viewport and rebuild lighting
Avoid the problem
- wait on lighting an area until you are nearly done with the architecture
- if you want to see the lighting before you finish
- save a copy of the map to some other name
- apply lighting.
Reduce your test lighting time by adding the lights to a single group in the group browser.
Unlit Surfaces
Whole Zone(s)
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
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
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
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):