Shapes ignoring sunlight on top of interiors
by Manoel Neto · in Torque Game Engine · 08/15/2005 (12:46 pm) · 14 replies
Hi,
I'm using a massive .DIF as pavement in our mission, and the character/staticShape lighting goes fubar when the objects are on the pavement. They seems to be ignoring sunlight, as if they were inside interiors. No matter how high I place the objects, seems they are treated as "inside" if their X and Y coordinates are inside an interior, regardless of Z value. Is it supposed to behave this way, or is there a problem with our interiors? I'd love to find a solution, since this drastically changes the lighting when the character walks from the terrain to the road.
I'm using a massive .DIF as pavement in our mission, and the character/staticShape lighting goes fubar when the objects are on the pavement. They seems to be ignoring sunlight, as if they were inside interiors. No matter how high I place the objects, seems they are treated as "inside" if their X and Y coordinates are inside an interior, regardless of Z value. Is it supposed to behave this way, or is there a problem with our interiors? I'd love to find a solution, since this drastically changes the lighting when the character walks from the terrain to the road.
About the author
Recent Threads
#2
08/15/2005 (1:20 pm)
Yes. When I do that, the statics become 100% dark. No sunlight.
#3
There was a bug in version 1.3 that caused static DTS objects with receiveSunLight enabled to not work properly over interiors, but it's fixed in 1.3.5 (not sure which version you're running).
Dynamic DTS objects like players and vehicles select their lighting from the interior or terrain directly beneath them, so if the object is on or above an interior the lighting will come from the interior and not the sun, TGE (and the Lighting Pack) do not distinguish between being inside or on an interior.
Let me know if this makes sense,
-John
08/15/2005 (4:21 pm)
Hi Manoel,There was a bug in version 1.3 that caused static DTS objects with receiveSunLight enabled to not work properly over interiors, but it's fixed in 1.3.5 (not sure which version you're running).
Dynamic DTS objects like players and vehicles select their lighting from the interior or terrain directly beneath them, so if the object is on or above an interior the lighting will come from the interior and not the sun, TGE (and the Lighting Pack) do not distinguish between being inside or on an interior.
Let me know if this makes sense,
-John
#4
Do you have suggestions for upgrading to version 1.35 while keeping my changes in? I'm thinking of diff'ing my modified source tree against the original LP 1.3 tree using TortoiseMerge, creating a patch and applying it to LP 1.35. Would that work?
08/16/2005 (6:09 am)
It does make sense, I'm using version 1.3. Also the problem became visible after turning on sgDynamicDTSVectorLighting (the players' lighting was *very* bland with that setting off, and there was almost no shading on our high-poly characters, rendering the high-polycound nearly useless - we have been forced to bake "lightmaps" onto our characters textures on a previous project using 1. because we didn't know about sgDynamicDTSVectorLighting).Do you have suggestions for upgrading to version 1.35 while keeping my changes in? I'm thinking of diff'ing my modified source tree against the original LP 1.3 tree using TortoiseMerge, creating a patch and applying it to LP 1.35. Would that work?
#5
- back up the current working source (C++ and scripts).
- use WinMerge (or a similar diff tool) to merge the 1.3.5 changes into your project. Because you're running 1.3, most of the changes are already in your code. The core Lighting Pack source files changed a lot, so when you get to those you can just move all of the file changes over at once using the 'all left' or 'all right' button (assuming you haven't modified the files).
- then use the Migration Guide to see which files need to be added to your project (at the bottom of the guide), again most of them are already in your project from version 1.3 of the Lighting Pack.
- compile and enjoy. :)
All of the Lighting Pack changes to the TGE code are clearly commented so moving only the 1.3.5 changes into your project should be a snap.
Let me know if this helps!
-John
08/16/2005 (11:32 am)
I would just:- back up the current working source (C++ and scripts).
- use WinMerge (or a similar diff tool) to merge the 1.3.5 changes into your project. Because you're running 1.3, most of the changes are already in your code. The core Lighting Pack source files changed a lot, so when you get to those you can just move all of the file changes over at once using the 'all left' or 'all right' button (assuming you haven't modified the files).
- then use the Migration Guide to see which files need to be added to your project (at the bottom of the guide), again most of them are already in your project from version 1.3 of the Lighting Pack.
- compile and enjoy. :)
All of the Lighting Pack changes to the TGE code are clearly commented so moving only the 1.3.5 changes into your project should be a snap.
Let me know if this helps!
-John
#6
But the main problem still persists. The odd behavior was fixed for staticshapes, now they still receive sunlight even when placed on the pavement, but the player lighting will completly change when doing the same.
Actually, it looks like the effects of sgDynamicDTSVectorLighting are nullfied when there's an interor below the character location.
08/16/2005 (1:30 pm)
I performed the merge. W00t, dynamic shadows! But the main problem still persists. The odd behavior was fixed for staticshapes, now they still receive sunlight even when placed on the pavement, but the player lighting will completly change when doing the same.
Actually, it looks like the effects of sgDynamicDTSVectorLighting are nullfied when there's an interor below the character location.
#7
From above:
You could update SceneObject::installLights to calculate the object's exact zone and then only use the directional lighting while entirely in zone 0 (outside), but calculating a point's zone does create overhead. You can also use the object's currZones list, but it can give conflicting info depending on the location and orientation of the object and the interior below it.
08/16/2005 (3:44 pm)
Yes. :)From above:
Quote:
Dynamic DTS objects like players and vehicles select their lighting from the interior or terrain directly beneath them, so if the object is on or above an interior the lighting will come from the interior and not the sun, TGE (and the Lighting Pack) do not distinguish between being inside or on an interior.
You could update SceneObject::installLights to calculate the object's exact zone and then only use the directional lighting while entirely in zone 0 (outside), but calculating a point's zone does create overhead. You can also use the object's currZones list, but it can give conflicting info depending on the location and orientation of the object and the interior below it.
#8
If that doesn't work, where should I look in order to disable the sunlight discarding (thus making it work like the terrain does)? I'm thinking about doing a raycast against interiors in the sun durection instead, and checking if it hits something, to decide if the character needs to receive sinlight or not (if it works, as a nice side-effect, the character will be properly shadowed when walking behind an interor).
08/17/2005 (7:56 am)
I'll give a look on the currZones list, but I have a feeling it might not solve the problem, since I suspect that the fact of the pavement AND walls being part of the same dif causes the player to be comsidered inside the DIF box, even if it's in an open area.If that doesn't work, where should I look in order to disable the sunlight discarding (thus making it work like the terrain does)? I'm thinking about doing a raycast against interiors in the sun durection instead, and checking if it hits something, to decide if the character needs to receive sinlight or not (if it works, as a nice side-effect, the character will be properly shadowed when walking behind an interor).
#9
In sgSceneObject.cc, this code just uses the mLightSource info to decide if the sunlight will be taken in account or not:
For now, I'll just change it so the sunlight is always there, since it suits better the project needs. I'll try to add the sun raycasting later, since it will require some extra code to avoid lots and lots of useless raycasting.
08/17/2005 (9:25 am)
After a quick glance, seems I'll have to go the 2nd route. Seems TGE just cast a ray down, and if hits an interior, mLightingInfo.mLightSource is set to LightingInfo::Interior, otherwise it's set to SceneObject::LightingInfo::Terrain. In sgSceneObject.cc, this code just uses the mLightSource info to decide if the sunlight will be taken in account or not:
if ( (obj->mLightingInfo.mLightSource == SceneObject::LightingInfo::Terrain)
&& (sgLightManager::sgDynamicDTSVectorLighting))
{
F32 factor = mClampF((ambientColor.red + ambientColor.green + ambientColor.blue) / 3.f, 0.f, 1.f);
lightManager->setVectorLightsAttenuation(factor);
}
else
{
...For now, I'll just change it so the sunlight is always there, since it suits better the project needs. I'll try to add the sun raycasting later, since it will require some extra code to avoid lots and lots of useless raycasting.
#10
08/17/2005 (9:59 am)
UDPATE: I sorted it out by replacing the installLights call for sceneObjects by installLightsAdvanced (that was used by TSStatic and staticShapes). It seems to do the job, at a quick look. Is there any advice against doing so?
#11
Actually before you devote too much time to it let me take a quick look. I know exactly how I would go about making the change, but I also want to make sure it works before sending you down that road.
08/17/2005 (11:19 am)
I should have been more clear with the object currZones issue - the zone list is always accurate and is extremely handy to have around. My concern is that while standing in an interior zone (say zone 1) if the player is against the wall its bounding box could extend slightly beyond the wall and include zone 0 too, making it difficult to decide exactly where the player is located. Having said that I would still give it a try.Actually before you devote too much time to it let me take a quick look. I know exactly how I would go about making the change, but I also want to make sure it works before sending you down that road.
#12
Let me know how this works for you
-John
Edit: Btw - this also fixes a bug where dynamic objects seem fully illuminated while over a shadow (when using directional lighting).
08/17/2005 (2:07 pm)
Ok, I've put together a better directional lighting solution that allows dynamic DTS objects to continue receiving directional lighting while on interiors and still fully contained in zone 0 (the outside). When the object is partially or fully contained in a zone other than 0 it switches to ambient lighting.Let me know how this works for you
-John
Edit: Btw - this also fixes a bug where dynamic objects seem fully illuminated while over a shadow (when using directional lighting).
#13
Line 14 change:
To:
Line 227 change:
To:
File 'engine/synapseGaming/contentPacks/lightingPack/sgSceneObject.cc'
Line 172 change:
To:
08/17/2005 (2:07 pm)
File 'engine/synapseGaming/contentPacks/lightingPack/sgLightingModel.cc'Line 14 change:
#include "synapseGaming/contentPacks/lightingPack/sgLightingModel.h" #include "sceneGraph/lightManager.h" #define SG_LIGHTING_MIN_CUTOFF 0.00392f
To:
#include "synapseGaming/contentPacks/lightingPack/sgLightingModel.h" #include "sceneGraph/lightManager.h" [b]#include "sceneGraph/sceneGraph.h"[/b] #define SG_LIGHTING_MIN_CUTOFF 0.00392f [b]extern SceneGraph *gClientSceneGraph;[/b]
Line 227 change:
F32 ambientFactor = (sgLightParamAmbient[0] + sgLightParamAmbient[1] + sgLightParamAmbient[2]) / 3.0f; F32 factor = mClampF(1.0 - ambientFactor, 0.f, 1.f); // attenuate (for in shadow...) sgLightParamDiffuse.x *= factor; sgLightParamDiffuse.y *= factor; sgLightParamDiffuse.z *= factor;
To:
F32 ambientFactor = (sgLightParamAmbient[0] + sgLightParamAmbient[1] + sgLightParamAmbient[2]) / 3.0f; [b]F32 factor; LightManager *lm = gClientSceneGraph->getLightManager(); if(lm && lm->getVectorLightsEnabled()) factor = mClampF(lm->getVectorLightsAttenuation() - ambientFactor, 0.f, 1.f); else factor = mClampF(1.0f - ambientFactor, 0.f, 1.f); [/b] // attenuate (for in shadow...) sgLightParamDiffuse.x *= factor; sgLightParamDiffuse.y *= factor; sgLightParamDiffuse.z *= factor;
File 'engine/synapseGaming/contentPacks/lightingPack/sgSceneObject.cc'
Line 172 change:
// install the lights:
LightManager * lightManager = gClientSceneGraph->getLightManager();
AssertFatal(lightManager!=NULL, "SceneObject::installLights: LightManager not found");
ColorF ambientColor;
if(obj->getLightingAmbientColor(&ambientColor))
{
if((obj->mLightingInfo.mLightSource == SceneObject::LightingInfo::Terrain) &&
(sgLightManager::sgDynamicDTSVectorLighting))
{
F32 factor = mClampF((ambientColor.red + ambientColor.green + ambientColor.blue) / 3.f, 0.f, 1.f);
lightManager->setVectorLightsAttenuation(factor);
}To:
// install the lights:
LightManager * lightManager = gClientSceneGraph->getLightManager();
AssertFatal(lightManager!=NULL, "SceneObject::installLights: LightManager not found");
[b]
// testing...
bool allowdirectional = false;
if(sgLightManager::sgDynamicDTSVectorLighting)
{
allowdirectional = (obj->getNumCurrZones() == 1) && (obj->getCurrZone(0) == 0);
}
[/b]
ColorF ambientColor;
if(obj->getLightingAmbientColor(&ambientColor))
{
[b] if(//(obj->mLightingInfo.mLightSource == SceneObject::LightingInfo::Terrain) &&
(allowdirectional))[/b]
{
F32 factor = mClampF((ambientColor.red + ambientColor.green + ambientColor.blue) / 3.f, 0.f, 1.f);
lightManager->setVectorLightsAttenuation(factor);
}
#14
08/18/2005 (5:45 am)
Wow, such a much better solution in such short time! It seems to work very nice now. I don't have any interiors with portals/zones at hand to check what'll happen when the player is inside them, though, but the outdoor results are much better now.
Torque 3D Owner Jackie Hayes