TSE Lighting System Q&A
by John Kabus (BobTheCBuilder) · in Torque Game Engine Advanced · 09/07/2006 (4:53 am) · 49 replies
*Update*: The Torque Lighting System TDN section is nearly complete and now covers Torque Advanced (TSE), TGE 1.5, and TLK. The Torque Advanced (TSE) section was updated to include info on Lighting and Shadows, Performance Considerations, and updates and additions to the original articles. All articles were updated to include information on TGE 1.5 and note any differences between Torque Advanced, TGE 1.5, and TLK.
-John Kabus (9/30/2006)
//---------------------------------------------
TSE Lighting System Q&A
This is the official Lighting System Q&A thread. I'd like to try and keep the questions here so they are easier to answer and easier to find.
I'm happy to answer any Lighting System questions, but please read the
TSE Lighting System Documentation
First to see if your questions have already been answered.
Lighting
Static and dynamic lighting is setup for the legacy terrain (unless you're using custom shaders, but creating a custom lighting shader is a snap - I need to create a TDN article around that process), Atlas changed recently to add the new clip mapping, we're working on adding the static and dynamic lighting back in for 1.0.
So static and dynamic lighting works on all objects except Atlas (however dynamic DTS shadows do cast onto Atlas). Because the static lighting is not yet implemented Atlas uses the baked in light map provided when importing, so the lighting direction may look off, because Atlas is not yet using TSE lighting.
Dynamic Shadows
Regarding dynamic shadows; the shadows clip against interiors, terrain and Atlas similar to TGE dynamic shadows. This prevents the shadows from casting through walls. If you notice gaps it's due to the clipping - lowering the projection distance limits the likelihood of clipping.
Also you may notice that fluffy's shadow gets clipped near his head, this is because the bounding box doesn't completely enclose the mesh. You can account for this by using the object's datablock property shadowSphereAdjust. For more details check out the TDN article:
Dynamic Shadows.
HDR/DRL
I've also seen a few questions regarding the HDR system - it should be in and fully functional. HDR is controlled using the mission's sun object (the commented out prefs are from a prototype version that used prefs, I switched it to the sun, so HDR can be controlled per-mission) - make sure DRL is enabled too (HDR uses the underlying DRL system, but modifies it to use higher precision data), for details see the TDN article:
HDR and DRL
Also make sure Dynamic Range Lighting is enabled in the options dialog (or use the pref $pref::LightManager::sgUseDynamicRangeLighting).
-John Kabus (9/30/2006)
//---------------------------------------------
TSE Lighting System Q&A
This is the official Lighting System Q&A thread. I'd like to try and keep the questions here so they are easier to answer and easier to find.
I'm happy to answer any Lighting System questions, but please read the
TSE Lighting System Documentation
First to see if your questions have already been answered.
Lighting
Static and dynamic lighting is setup for the legacy terrain (unless you're using custom shaders, but creating a custom lighting shader is a snap - I need to create a TDN article around that process), Atlas changed recently to add the new clip mapping, we're working on adding the static and dynamic lighting back in for 1.0.
So static and dynamic lighting works on all objects except Atlas (however dynamic DTS shadows do cast onto Atlas). Because the static lighting is not yet implemented Atlas uses the baked in light map provided when importing, so the lighting direction may look off, because Atlas is not yet using TSE lighting.
Dynamic Shadows
Regarding dynamic shadows; the shadows clip against interiors, terrain and Atlas similar to TGE dynamic shadows. This prevents the shadows from casting through walls. If you notice gaps it's due to the clipping - lowering the projection distance limits the likelihood of clipping.
Also you may notice that fluffy's shadow gets clipped near his head, this is because the bounding box doesn't completely enclose the mesh. You can account for this by using the object's datablock property shadowSphereAdjust. For more details check out the TDN article:
Dynamic Shadows.
HDR/DRL
I've also seen a few questions regarding the HDR system - it should be in and fully functional. HDR is controlled using the mission's sun object (the commented out prefs are from a prototype version that used prefs, I switched it to the sun, so HDR can be controlled per-mission) - make sure DRL is enabled too (HDR uses the underlying DRL system, but modifies it to use higher precision data), for details see the TDN article:
HDR and DRL
Also make sure Dynamic Range Lighting is enabled in the options dialog (or use the pref $pref::LightManager::sgUseDynamicRangeLighting).
#2
09/07/2006 (6:54 pm)
Have the same problem as Ishbuu. *downloads latest head*
#3
09/07/2006 (7:14 pm)
Pulling the latest head, or doing a cvs update on the source tree should pull down the latest textures (I verified it here by doing an update).
#4
09/07/2006 (7:21 pm)
Oh my, HDR, bloom, and the overall lighting ROCKS.
#5
09/07/2006 (7:32 pm)
Thanks! :) 
#6
09/07/2006 (9:01 pm)
Great Job John!!Thanks for all the hard work now I can start to finish my worlds lighting!!
#7
Stream handling of math types can be found in mathIO.h:
09/07/2006 (10:59 pm)
Saw a comment in sgDecalProjector: "// this is a joke right (no Point3F support)?!?"Stream handling of math types can be found in mathIO.h:
mathWrite(*stream, sgProjectionPoint); mathWrite(*stream, sgProjectionNormal);
mathRead(*stream, &sgProjectionPoint); mathRead(*stream, &sgProjectionNormal);
#8
09/07/2006 (11:30 pm)
Hi Jeff, thanks. That is fairly old TLK code - I think it was from the 1.3.5 release, around a year and a half ago. I'm sure there are lots of funny little comments throughout the lighting system code. :)
#9
09/08/2006 (4:50 pm)
John: are there any controlls that allow you to change the time it takes for exposure to fix itself? Like in DRL how it allows you to modify the time it takes to adjust to the new light exposure level.
#10
09/08/2006 (6:59 pm)
No, I tried to avoid that for performance reasons - multi-frame exposure changes require reading data back from the card, which is slow. I did performance testing with read-backs and the hit was hard even when reading a single pixel from the last render target, due to stalls in the cpu->gpu pipeline.
#11
09/08/2006 (7:49 pm)
Ah. Damn shame, its a very cool effect :( But very well, no complaints, it still rocks :) Are there any plans to write a new decal system based on the shadows or should I get started on writing that myself? Real decals would be a very cool touch for TSE.
#12
09/08/2006 (10:39 pm)
I haven't heard of anything in the works, you might want to take a crack at it. I'd say starting with the dynamic shadow code could help out a lot - it already conforms to interiors, Atlas, and the terrain, and it clips, stopping it from casting through walls.
#13
I just brought the spaceorc and crossbow into the M4 water demo, and they both are very dull. They have a brown tinge as though they are in a dim interior instead of out in the sunlight. I have an interior next to the orc which is lit normally. Is there some setting I have to use to light the player character when he's outside?
Thx,
Dave.
09/13/2006 (7:38 am)
Hi,I just brought the spaceorc and crossbow into the M4 water demo, and they both are very dull. They have a brown tinge as though they are in a dim interior instead of out in the sunlight. I have an interior next to the orc which is lit normally. Is there some setting I have to use to light the player character when he's outside?
Thx,
Dave.
#14
09/13/2006 (7:58 am)
Did you assign a material to it, Dave?
#15
Everything looks fine except it isn't lit correctly. If I take the orc into an interior it is lit correctly, and even changes colour with the lights I have inside. It's only outside it looks brown and muddy.
Dave.
09/13/2006 (8:05 am)
Yep, the materials file is in the orc directory, the materials are all there on the orc and also on the crossbow (had to make a materials file for the crossbow earlier today).Everything looks fine except it isn't lit correctly. If I take the orc into an interior it is lit correctly, and even changes colour with the lights I have inside. It's only outside it looks brown and muddy.
Dave.
#16
DTS objects can't pick up environmental lighting from Atlas yet (because of Atlas' lack of engine lighting). Once we get Atlas' lighting setup DTS lighting will work just as well as on the legacy terrain and on interiors.
09/13/2006 (10:15 am)
Hi guys,DTS objects can't pick up environmental lighting from Atlas yet (because of Atlas' lack of engine lighting). Once we get Atlas' lighting setup DTS lighting will work just as well as on the legacy terrain and on interiors.
#17
I'm not sure if we're talking about the same thing. My problem is that the player character (orc) doesn't seem to be picking up the ambient lighting properly. Or more correctly, it looks sort of brown, like the shadowed side of my building is. So it looks like the engine thinks the orc is in the shade even though it's standing out in the open. I wouldn't have thought this has anything to do with Atlas, or has it?
Just to say that the building and also a static DTS that I made both look fine. It's just the spaceOrc. I loaded the orc as an AIPlayer as well and the AIPlayer is dull brown over the textures as well. I walked all around it, but the lighting is the same from all sides, as if the sun isn't there.
Thanks a lot,
Dave.
09/13/2006 (11:20 am)
Hi John,I'm not sure if we're talking about the same thing. My problem is that the player character (orc) doesn't seem to be picking up the ambient lighting properly. Or more correctly, it looks sort of brown, like the shadowed side of my building is. So it looks like the engine thinks the orc is in the shade even though it's standing out in the open. I wouldn't have thought this has anything to do with Atlas, or has it?
Thanks a lot,
Dave.
#18
I've read the bit about tone mapping on TDN and don't really understand it. Well, I understand the concept as I enjoy photography, but don't understand what it is you adjust in the settings or prefs to decide whether you go towards blue or yellow. Or maybe it's automatic?
Anyway, problem solved although reason for problem eludes me,.
Thanks,
Dave.
09/13/2006 (12:00 pm)
Aha! Got it sussed. I had useToneMapping turned on. I don't know why that would match the player in a scene to what looks like daylight balanced film used in tungsten light, but that's what it seems to be doing.I've read the bit about tone mapping on TDN and don't really understand it. Well, I understand the concept as I enjoy photography, but don't understand what it is you adjust in the settings or prefs to decide whether you go towards blue or yellow. Or maybe it's automatic?
Anyway, problem solved although reason for problem eludes me,.
Thanks,
Dave.
#19
Tone mapping automatically adjusts to the optimal setting, however you can adjust the tone mapping data to change the effect, its source is in the texture 'example/common/lighting/sgToneMap.png'. The left most area is the underexposed reference and the right is the overexposed reference. Adjusting the gray crossover point, or widening/narrowing it, affects the film/color balance.
The data is stored in half intensity values to avoid saturation and to provide additional headroom for stylized effects. ;)
09/13/2006 (12:41 pm)
The DTS environmental lighting is pulled from the light map of the object directly beneath the object (in this case Atlas). Because the Atlas lighting is not in TSE yet the lighting defaults to a mid intensity (0.5, 0.5, 0.5), this causes Fluffy to appear darker than normal, and causes the tone mapping to treat that area of the screen as underexposed (regarding film/color balance).Tone mapping automatically adjusts to the optimal setting, however you can adjust the tone mapping data to change the effect, its source is in the texture 'example/common/lighting/sgToneMap.png'. The left most area is the underexposed reference and the right is the overexposed reference. Adjusting the gray crossover point, or widening/narrowing it, affects the film/color balance.
The data is stored in half intensity values to avoid saturation and to provide additional headroom for stylized effects. ;)
Torque Owner Ishbuu
[Ishbuu]