ascottk on 12/9/2005 at 05:30
Ever since I starting using my installation with custom textures I've been getting strange lighting problems. As some of you know I have a lot of hidden doors on my map but the doors are not lighting properly any more. It looks fine in the editor but in-game the hidden doors look darker. I used the overlit geometry mode & the walls surrounding the door are brighter than the door (the bsp walls would be orange & the door would be yellow or green).
I only have one hidden door that is truly hidden & I managed to fix a couple of others by adding another light (omni-noshadow) close to the door near the floor. The radii of these lights cover the smesh door & I tried to match the colors in overlit geometry mode. Some of these doors refuse to light properly.
I've tried moving around the lights (one door that stayed hidden was in the middle of two lights, another was lined up with another) but no go.
I've tried turning shadow casting to either the door or the surrounding bsp. No go.
I've tried different radii, brightness, light dampening, ShadowExtrusion, etc.
I checked the alignment of the doors to the bsp. They are air tight. I aligned the textures of the bsp to match the smesh (otherwise you'd see these so-called "hidden doors"). I had to Flip U in order to match the mesh.
All this started happening with custom textures. But I don't understand why a couple of these doors light properly with minimal effort while others refuse to be lit. BTW the doors have been copied & pasted so they have the same qualities (I might copy the doors that do work & see if that'll work). Has anyone run into the same problem?
EDIT: I take that back. I altered a lot of these doors. Some are hinged, some are sliding and I duplicated the doors with similar properties. I also have doors with different textures & they have the same problem. Highlight distance is different for a lot of these doors. Some open manually while others open by scripts so the highlight doesn't factor in.
OrbWeaver on 12/9/2005 at 11:44
Meshes and BSP are processed separately, which is why the lighting does not always match. This was one of the motivations behind Doom 3's "unified lighting model" which ensures that all polys are rendered the same way. Unfortunately there is not much you can do about it except try to match them up as far as possible using trial and error.
rujuro on 12/9/2005 at 14:18
That's odd, my meshes and BSP light identically, in fact, it seems unified to me. That's been on of the strengths I've noticed in working with this engine. Like Doom 3, I've been unable to differentiate mesh from BSP.
Do you have any zone portals in the area? They can sometimes effect the lighting.
str8g8 on 12/9/2005 at 15:10
I've found materials lighting pretty consistently on smeshes and bsps as well. However, I can imagine that if you wanted them to match exactly (for the purposes of a secret door where the wallpaper seamlessly covers the outline of the door, then you might notice a discrepency) ...
Perhaps some screenshots might help us see the severity of the problem?
cheers
str8g8
ascottk on 12/9/2005 at 17:03
Quote Posted by str8g8
Perhaps some screenshots might help us see the severity of the problem?
Sorry . . . I was going to posts some screenshots in the original post but my computer keeps freezing up when I'm uploading pictures :p (firefox + imageshack, hasn't happened before) Anyway I've been using the GIMP with the latest normal map & dds plugin. I usually go with DDS 3 with mipmapping. Should I go with DDS 1?
str8g8 on 12/9/2005 at 17:22
Quote:
I usually go with DDS 3 with mipmapping. Should I go with DDS 1
If you mean DXT3 (as its written in the photoshop save as dialog) then no, DXT3 has an alpha channel and should only be used for things like particles and foliage.
Stick with DXT1. Also, I believe Flesh doesn't use the mip mapping (someone please correct me if I'm wrong - but none of the original textures seem to use them) so you can do without them as well.
hope this helps
cheers
str8g8
Ziemanskye on 13/9/2005 at 11:09
Does the new texture use normalmaps?
Just maybe if it doesn't (and this is a bit of a long shot) it's lit like a plain Smesh in UT2k3 - by vertex rather than by pixel, and most of the smeshes were built with very few vertices.
ascottk on 13/9/2005 at 16:23
Quote Posted by Ziemanskye
Does the new texture use normalmaps?
Just maybe if it doesn't (and this is a bit of a long shot) it's lit like a plain Smesh in UT2k3 - by vertex rather than by pixel, and most of the smeshes were built with very few vertices.
They do use normalmaps. str8g8's texture pack doesn't include non-normalmapped stuff (aside from the glass & sky). That could be the problem.
OrbWeaver on 13/9/2005 at 16:30
Quote Posted by Ziemanskye
Just maybe if it doesn't (and this is a bit of a long shot) it's lit like a plain Smesh in UT2k3 - by vertex rather than by pixel, and most of the smeshes were built with very few vertices.
I think they're lit by both vertex and pixel. That would explain why sometimes the water tile meshes are not evenly lit and give nasty square blocks of different lighting.