Lighting Pack version 1.3.5 Release Notes
by John Kabus (BobTheCBuilder) · in Torque Game Engine · 04/27/2005 (6:37 pm) · 34 replies
Hello Lighting Pack community,
Welcome to the new Lighting Pack private forums!
Lighting Pack for TGE 1.3.5 - Release Notes
Introduction
We're going to try something a little different for this release: we're rolling out an early release to the Lighting Pack community while the finishing touches are added to the demo, documentation, and the press releases. The Lighting Pack download page (available in the 'Downloadable Products You Own' section of the 'My Garage' page on the GarageGames site) now has links to both versions 1.3 and 1.3.5 (the latest version) of the Lighting Pack, allowing you to choose the release that's right for you.
This Lighting Pack release is absolutely packed full of new features, tweaks and optimizations. In fact this release nearly doubles the number of features in the Lighting Pack. Most of the core Lighting Pack features were updated (all are still 100% backwards compatible) and extended to support the new features. All of the features, new and old, were heavily tested to verify that they're functionally sound and backward compatible, but with the number of updates added to the Lighting Pack something may have been missed. If you find anything odd or have any questions, please post them in the Lighting Pack forum.
Here are a few questions you may have about this release (based on questions I've received lately):
"Should I upgrade?"
Absolutely. If you see features that your game or project needs, then definitely upgrade to the latest version.
"I'm releasing a demo within a few weeks, should I upgrade?"
I would advise against it. Introducing new code (even your own) into a demo right before the release is always a risky move. Instead consider merging the Lighting Pack into a separate branch of your code for internal and/or demonstration purposes.
"It looks like the Modeler's Guide hasn't been updated."
That's correct, this is an early release and we're still working on the documentation, however the Migration Guide was updated to help with upgrades (don't use the online Migration Guide, use the new guide that ships with the Lighting Pack). This document (the Release Notes) covers a lot of the new Lighting Pack features and how to use them.
"Why is the Lighting Pack version only 1.3.5 when so many things were added after 1.3?"
The new Lighting Pack version number scheme is based on the TGE version number and the Lighting Pack Core Library version number. Using the TGE version avoids confusion for new and potential licensees (the Lighting Pack for TGE 1.3 is based on TGE 1.3).
"Why is the Lighting Pack based on TGE 1.3, I thought TGE 1.4 was out?"
TGE 1.4 is available, but it still contains many bugs. To ensure that teams could immediately begin to work with this release of the Lighting Pack, we decided to use the more stable TGE 1.3 as the base. The Lighting Pack has been tested on TGE 1.4, and apart from the renaming of the method 'getServerConnection' in 1.4, it works great. Once TGE 1.4 is completely ready the Lighting Pack can easily plug right in.
Latest Features
In this document we're going cover the latest major features and how they work. There are a ton of new features, so I've broken them into the following categories:
1. New Lighting Pack Editor
2. Lighting and Cinematic Filters
3. New and Custom Lighting Models
4. New Lighting Object Tools
5. Zone Based Lighting
6. Cool Misc Features
...
For more info check out the full Lighting Pack 1.3.5 Release Notes.
-John Kabus
Synapse Gaming
Welcome to the new Lighting Pack private forums!
Lighting Pack for TGE 1.3.5 - Release Notes
Introduction
We're going to try something a little different for this release: we're rolling out an early release to the Lighting Pack community while the finishing touches are added to the demo, documentation, and the press releases. The Lighting Pack download page (available in the 'Downloadable Products You Own' section of the 'My Garage' page on the GarageGames site) now has links to both versions 1.3 and 1.3.5 (the latest version) of the Lighting Pack, allowing you to choose the release that's right for you.
This Lighting Pack release is absolutely packed full of new features, tweaks and optimizations. In fact this release nearly doubles the number of features in the Lighting Pack. Most of the core Lighting Pack features were updated (all are still 100% backwards compatible) and extended to support the new features. All of the features, new and old, were heavily tested to verify that they're functionally sound and backward compatible, but with the number of updates added to the Lighting Pack something may have been missed. If you find anything odd or have any questions, please post them in the Lighting Pack forum.
Here are a few questions you may have about this release (based on questions I've received lately):
"Should I upgrade?"
Absolutely. If you see features that your game or project needs, then definitely upgrade to the latest version.
"I'm releasing a demo within a few weeks, should I upgrade?"
I would advise against it. Introducing new code (even your own) into a demo right before the release is always a risky move. Instead consider merging the Lighting Pack into a separate branch of your code for internal and/or demonstration purposes.
"It looks like the Modeler's Guide hasn't been updated."
That's correct, this is an early release and we're still working on the documentation, however the Migration Guide was updated to help with upgrades (don't use the online Migration Guide, use the new guide that ships with the Lighting Pack). This document (the Release Notes) covers a lot of the new Lighting Pack features and how to use them.
"Why is the Lighting Pack version only 1.3.5 when so many things were added after 1.3?"
The new Lighting Pack version number scheme is based on the TGE version number and the Lighting Pack Core Library version number. Using the TGE version avoids confusion for new and potential licensees (the Lighting Pack for TGE 1.3 is based on TGE 1.3).
"Why is the Lighting Pack based on TGE 1.3, I thought TGE 1.4 was out?"
TGE 1.4 is available, but it still contains many bugs. To ensure that teams could immediately begin to work with this release of the Lighting Pack, we decided to use the more stable TGE 1.3 as the base. The Lighting Pack has been tested on TGE 1.4, and apart from the renaming of the method 'getServerConnection' in 1.4, it works great. Once TGE 1.4 is completely ready the Lighting Pack can easily plug right in.
Latest Features
In this document we're going cover the latest major features and how they work. There are a ton of new features, so I've broken them into the following categories:
1. New Lighting Pack Editor
2. Lighting and Cinematic Filters
3. New and Custom Lighting Models
4. New Lighting Object Tools
5. Zone Based Lighting
6. Cool Misc Features
...
For more info check out the full Lighting Pack 1.3.5 Release Notes.
-John Kabus
Synapse Gaming
#3
04/27/2005 (7:24 pm)
Amazing work John! Absolutely amazing! Thank you!! 
#4
John, any change the memory usage issue was addressed?
-Josh
04/27/2005 (8:07 pm)
Wow... this looks amazing!John, any change the memory usage issue was addressed?
-Josh
#5
Hi Josh,
The overall light mapping architecture is the same, so the memory footprint is the same. Did you have any luck turning down the light map border size?
Oh, there was a difference in interiorLMManager between TGE 1.3 and 1.4, but I believe it was only a small memory leak related to a pointer array not being cleaned up (but it might be worth a look).
-John
04/27/2005 (8:26 pm)
Thanks Eric!Hi Josh,
The overall light mapping architecture is the same, so the memory footprint is the same. Did you have any luck turning down the light map border size?
Oh, there was a difference in interiorLMManager between TGE 1.3 and 1.4, but I believe it was only a small memory leak related to a pointer array not being cleaned up (but it might be worth a look).
-John
#6
-Josh
04/27/2005 (8:39 pm)
By dropping the border size to 0 one of the missions went from using 700+ megs to using around 200 megs ... that border fix is a pretty big problem actually.-Josh
#7
04/27/2005 (8:45 pm)
The only other way I could avoid the border was to use nearest filtering on the light maps, which looked *bad* (ugh...), but that prevented the border color from bleeding onto the light maps when AA was in use (the issue seems to be isolated to AA filtering).
#8
Sorry to bring up a problem :)
The new updates look totally hot!!! Very exciting stuff!!!
-Josh
04/27/2005 (8:55 pm)
John, Sorry to bring up a problem :)
The new updates look totally hot!!! Very exciting stuff!!!
-Josh
#9
In lightManager.cc, shouldn't the else be uncommented? Or is this simply a "fallthrough" technique?
04/27/2005 (9:02 pm)
John,In lightManager.cc, shouldn't the else be uncommented? Or is this simply a "fallthrough" technique?
const Point3F LightManager::getShadowLightDirection() const
{
if(mSunLight)
return mSunLight->mDirection;
//-----------------------------------------------
// Lighting Pack code block
//-----------------------------------------------
//else
return Point3F(0, 0, -1.0);
#10
There was an issue with the way light maps were calculate in version 1.3 of the Lighting Pack, which caused all light maps to be duplicated (a process that occurs naturally in the interior light map manager during scene lighting while the cached (interior owned) light maps are duplicated for interior instances). The problem was that the Lighting Pack code was creating duplicate light maps even if the light maps didn't change (which means only the cached interior owned light maps were need, but identical copies were created).
This was resolved with the new floating point accumulation buffers. Now only changed light maps are duplicated, however during my testing it appeared that TGE's scene lighting itself was duplicating these light maps for writing the ambient lighting into each interior instance (can't imagine why that would happen, ambient lighting by nature is constant). Whether or not TGE is actually duplicating the light maps, or I'm crazy and imagined to whole thing I can't say, but you may notice a difference (for the better) in memory usage.
No problem bringing it up this is a great question.
Hi Desmond,
That's the old fall-through. :)
-John
04/27/2005 (9:07 pm)
Oh, wait (so many features in this release I can't keep them straight... :)...There was an issue with the way light maps were calculate in version 1.3 of the Lighting Pack, which caused all light maps to be duplicated (a process that occurs naturally in the interior light map manager during scene lighting while the cached (interior owned) light maps are duplicated for interior instances). The problem was that the Lighting Pack code was creating duplicate light maps even if the light maps didn't change (which means only the cached interior owned light maps were need, but identical copies were created).
This was resolved with the new floating point accumulation buffers. Now only changed light maps are duplicated, however during my testing it appeared that TGE's scene lighting itself was duplicating these light maps for writing the ambient lighting into each interior instance (can't imagine why that would happen, ambient lighting by nature is constant). Whether or not TGE is actually duplicating the light maps, or I'm crazy and imagined to whole thing I can't say, but you may notice a difference (for the better) in memory usage.
No problem bringing it up this is a great question.
Hi Desmond,
That's the old fall-through. :)
-John
#11
04/27/2005 (9:37 pm)
Hmm, still double posting when using back
#12
04/27/2005 (9:57 pm)
Could this duplication have caused the shared edge problem I discussed with you previously?
#14
Did you increase the scale of the interior in an attempt to preserve its detail? That could have preserved any uneven surfaces too.
Also if the lighting scale is very high (smaller light maps) the light mapper could be calculating the next lexel all the way into the building, because of the low lexel density.
Hi Tim,
Thanks man!
04/28/2005 (1:27 pm)
Desmond, the edge problem seemed related to exporting the map with floating point coords (though I think you tested the dif without floats) or having two adjacent uneven surfaces, which are used to represent one flat surface. Btw: those edges were created by TGE's directional lighting (which I've left untouched) - I'm not sure how it's happening without float coords, in TGE or in the Lighting Pack.Did you increase the scale of the interior in an attempt to preserve its detail? That could have preserved any uneven surfaces too.
Also if the lighting scale is very high (smaller light maps) the light mapper could be calculating the next lexel all the way into the building, because of the low lexel density.
Hi Tim,
Thanks man!
#15
04/28/2005 (4:39 pm)
I just got done merging the old one..AARRRGGHH....I love you guys.
#16
04/28/2005 (8:14 pm)
John, are the editable .gui files available for the sgLightEditor? The .dso you provided use the default Torque Demo directories for the scroll, check and menu GUI profiles. I have a completely different directory structure, so it will not work properly for me...I tried to edit the .dso files but the app didn't like me doing that :)
#17
The Lighting Pack specific script files were removed, because they were being deployed in demos by several team's (against the Lighting Pack license). This is an easy mistake to make when source files are contained in the game asset tree (like the script files are), so the script files were replaced with a new script library system, which is cross-platform, modular, and can safely be deployed with your projects.
The editable fields ($sgLightEditor::lightDBPath and $sgLightEditor::filterDBPath) are now in 'common\synapseGaming\contentPacks\sgDeploy.cs', so they can be edited.
The whole script library uses relative paths, so as long as you move the 'synapseGaming' folder into a main mod directory (like 'common', 'starter.fps', or whatever your mod is named) you'll be fine. Remember to update the calls to exec in '.../server/game.cs' and '.../client/init.cs' to point to the new 'sgDeploy*.cs' locations.
04/28/2005 (8:33 pm)
Hi Jacob,The Lighting Pack specific script files were removed, because they were being deployed in demos by several team's (against the Lighting Pack license). This is an easy mistake to make when source files are contained in the game asset tree (like the script files are), so the script files were replaced with a new script library system, which is cross-platform, modular, and can safely be deployed with your projects.
The editable fields ($sgLightEditor::lightDBPath and $sgLightEditor::filterDBPath) are now in 'common\synapseGaming\contentPacks\sgDeploy.cs', so they can be edited.
The whole script library uses relative paths, so as long as you move the 'synapseGaming' folder into a main mod directory (like 'common', 'starter.fps', or whatever your mod is named) you'll be fine. Remember to update the calls to exec in '.../server/game.cs' and '.../client/init.cs' to point to the new 'sgDeploy*.cs' locations.
#18
Loading compiled script Game/GUI/System/SG/littleEndian/sgLightEditor.gui.
Could not locate texture: common/ui/darkScroll
Failed to load profile bitmap (common/ui/darkScroll)
Could not locate texture: common/ui/torqueCheck
Failed to load profile bitmap (common/ui/torqueCheck)
Could not locate texture: common/ui/torqueMenu
Failed to load profile bitmap (common/ui/torqueMenu)
...my Scroll, Check and Menu bitmaps that are being sought are in a totally different place:
Game/GUI/Bitmaps/System/DefaultScroll *** Notice the name of this png is also different ***
Game/GUI/Bitmaps/System/torqueCheck
Game/GUI/Bitmaps/System/torqueMenu
I believe that your suggestion above will not solve this. Hence, would you be willing to send me a new custom compliled .dso file with my directory/png names coded into it instead of common/ui?
04/28/2005 (8:49 pm)
Thanks for your quick reply...just to clarify I will post the error from the console:Loading compiled script Game/GUI/System/SG/littleEndian/sgLightEditor.gui.
Could not locate texture: common/ui/darkScroll
Failed to load profile bitmap (common/ui/darkScroll)
Could not locate texture: common/ui/torqueCheck
Failed to load profile bitmap (common/ui/torqueCheck)
Could not locate texture: common/ui/torqueMenu
Failed to load profile bitmap (common/ui/torqueMenu)
...my Scroll, Check and Menu bitmaps that are being sought are in a totally different place:
Game/GUI/Bitmaps/System/DefaultScroll *** Notice the name of this png is also different ***
Game/GUI/Bitmaps/System/torqueCheck
Game/GUI/Bitmaps/System/torqueMenu
I believe that your suggestion above will not solve this. Hence, would you be willing to send me a new custom compliled .dso file with my directory/png names coded into it instead of common/ui?
#19
04/29/2005 (9:07 am)
Hmm... didn't catch those. Better yet I'll update the script library to use a configurable path there too (just like the light and filter db paths) - I'll post an update soon. 
Torque Owner Desmond Fletcher
fletcher