Interior Lighting Bug Fix
by Eric Hartman · in Torque Game Engine · 11/14/2004 (4:00 am) · 9 replies
I havent checked if this is still in the latest head, but it probably is.
The Bug: Occasionally while running over oddly shaped pieces of an interior, the character's lighting will flash to full-bright. It can be quite distracting.
The Cause: The character's lighting is determined by a ray cast, and sometimes for whatever reason it doesnt turn out right.
The Fix:
in file sim/sceneObject.cc in the function bool SceneObject::getLightingAmbientColor(ColorF * col)
new code is in bold
this makes it use the lighting info from the last check if the current check fails
The Bug: Occasionally while running over oddly shaped pieces of an interior, the character's lighting will flash to full-bright. It can be quite distracting.
The Cause: The character's lighting is determined by a ray cast, and sometimes for whatever reason it doesnt turn out right.
The Fix:
in file sim/sceneObject.cc in the function bool SceneObject::getLightingAmbientColor(ColorF * col)
new code is in bold
// Ambient light is determined by the surface we are standing on.
RayInfo collision;
if (gClientContainer.castRay(pos, Point3F(pos.x, pos.y, pos.z - cRayLength),
InteriorObjectType | TerrainObjectType, &collision))
{
// Standing on an interior object
if (InteriorInstance * instance = dynamic_cast<InteriorInstance*>(collision.object))
{
if (collision.face != -1)
{
...
...
// use info if collided
mLightingInfo.mLightSource = LightingInfo::Interior;
mLightingInfo.mUseInfo = true;
}
[b]else
{
mLightingInfo.mLightSource = LightingInfo::Interior;
mLightingInfo.mUseInfo = true;
}[/b]this makes it use the lighting info from the last check if the current check fails
About the author
#2
11/14/2004 (5:53 am)
Thats probably the same thing that causes the fog to be the wrong color on the mac sometimes. I remember a thread about it a long time ago where i think someone had fixed it. It was described as an "Endian" issue, but I dont even know what that means.
#3
I'm quite sure it's a endian issue, since the endian is different on PCs and Macs. (PCs have little-endian and Macs big-endian).
Was the fix posted on the forums? (I have searched and not found anything)
11/14/2004 (6:01 am)
Yeah, I have that fog issue too.I'm quite sure it's a endian issue, since the endian is different on PCs and Macs. (PCs have little-endian and Macs big-endian).
Was the fix posted on the forums? (I have searched and not found anything)
#4
This is a good find:) I've also seen this on occasion but didn't know where to look, and now I know. Thanks.
The endianess is related to how data are stored in your platform. For example, Windows uses little endian and if you have an integer value = 0x1234(hex), it would stored it as 0x34, 0x12. The least significant (little) bytes (LSB) are stored first. Most other platforms uses big endian and stores most significant byte (MSB) first.
I'll also look into this and see if I see anything unusual.
11/14/2004 (6:02 am)
Eric,This is a good find:) I've also seen this on occasion but didn't know where to look, and now I know. Thanks.
The endianess is related to how data are stored in your platform. For example, Windows uses little endian and if you have an integer value = 0x1234(hex), it would stored it as 0x34, 0x12. The least significant (little) bytes (LSB) are stored first. Most other platforms uses big endian and stores most significant byte (MSB) first.
I'll also look into this and see if I see anything unusual.
#5
11/14/2004 (8:51 am)
Even if there are no lights in the interior it can still be lit by the sun. What i'm trying to figure out is how to tell the difference between light that comes from the .dif file and light that comes from the sun. I'm trying to fix the interior part of the day/night resource. I cant really figure out whats going on in the function though, so if you have any insight I'd like to hear it.
#6
The OSX fog fix:
Edit: Oh and perform a clean build after making the change.
-John
11/14/2004 (9:29 am)
Hey guys,The OSX fog fix:
[b]core/color.h[/b] line [b]436[/b] should read:
inline U32 ColorI::getRGBEndian() const
{
#if defined(TORQUE_OS_MAC)
return(getRGBPack());
#else
return(getBGRPack());
#endif
}Edit: Oh and perform a clean build after making the change.
-John
#8
I believe this is the difference between what's going on with the interior light source and when objects(players) are on terrain.
The interior light is always regitered in:
If you take a look at the switch statement for interior, you can see that ambient source is registered whenever a player is on the interior surface:
The terrain instance doesn't do this, hence, will result in using sun light ambient color. My guess is if a similar method is used for terrain as is done for the interior, i.e. register terrain lightmap color, you will achieve the same results.
As a test, I join the two case statements in installLights():
allowing terrain lightmap ambient color to also get registered, and the player displays similar effect as when it's on the interior surface.
11/14/2004 (10:28 am)
Eric,I believe this is the difference between what's going on with the interior light source and when objects(players) are on terrain.
The interior light is always regitered in:
void SceneObject::installLights()
If you take a look at the switch statement for interior, you can see that ambient source is registered whenever a player is on the interior surface:
lightManager->addLight(&mLightingInfo.smAmbientLight); lightManager->setVectorLightsEnabled(false);
The terrain instance doesn't do this, hence, will result in using sun light ambient color. My guess is if a similar method is used for terrain as is done for the interior, i.e. register terrain lightmap color, you will achieve the same results.
As a test, I join the two case statements in installLights():
case LightingInfo::Terrain: case LightingInfo::Interior:
allowing terrain lightmap ambient color to also get registered, and the player displays similar effect as when it's on the interior surface.
Torque 3D Owner abc
abc
http://bux.sytes.net/files/bug.mov
(That's on OSX, I didn't have this problem on Linux I think)
I thought that your code would fix it, but apparently it didn't.