Dynamic Range Lighting
by Jeff Raab · 03/07/2006 (11:21 am) · 54 comments
Download Code File
Alright, This resource allows you to add Dynamic Range Lighting to the TLK.
We've talked with John, and he helped us get this all together.
What you need to do is download the attached file, and copy the files over what's currently in your directory.(If you've modified these files, the relevent changes can be found pretty easily and moved into your files without much struggle)
Once you've got these copied over, go into your code and open sgLighting.h.
In there, find the defines near the top:
#define SG_LIGHTING
and
#define SG_USE_TERRAIN_COLOR_CORRECTION
and comment them out. If they stay active with DRL on, you'll get super brightened stuff, and that's just painful to look at.
Once those have been commented out, compile your code, and your done!
Load up a mission and run around and check out the apature adaptation, as well as blooming, etc.
Tips on performance management and modifying the DRL settings can be found in the included readme, as well as contact info if needed.
Enjoy!
-Jeff "Reno" Raab
-Alex "Delerium" Scarborough
Alright, This resource allows you to add Dynamic Range Lighting to the TLK.
We've talked with John, and he helped us get this all together.
What you need to do is download the attached file, and copy the files over what's currently in your directory.(If you've modified these files, the relevent changes can be found pretty easily and moved into your files without much struggle)
Once you've got these copied over, go into your code and open sgLighting.h.
In there, find the defines near the top:
#define SG_LIGHTING
and
#define SG_USE_TERRAIN_COLOR_CORRECTION
and comment them out. If they stay active with DRL on, you'll get super brightened stuff, and that's just painful to look at.
Once those have been commented out, compile your code, and your done!
Load up a mission and run around and check out the apature adaptation, as well as blooming, etc.
Tips on performance management and modifying the DRL settings can be found in the included readme, as well as contact info if needed.
Enjoy!
-Jeff "Reno" Raab
-Alex "Delerium" Scarborough
About the author
#22
Well i did merge the new platformVideo.cc before the whole crashing part, but i'm gonna look into it myself first for a bit, so i'll get back to ya later on this issue.
Edit: seems it was just the computer being weird.
The whole Matrox Parhelia card issue was just FYI although it runs OpenGL 1.3 everything goes black with a dark red sky. Luckily i have a NVIDI card on wich i normally run Torque so it's no biggie :) but i'll test some more. (it's always good to have it run on everything)
Edit: still black and red...
Back later with more :)
03/09/2006 (4:05 pm)
@Jeff "Reno": Well i did merge the new platformVideo.cc before the whole crashing part, but i'm gonna look into it myself first for a bit, so i'll get back to ya later on this issue.
Edit: seems it was just the computer being weird.
The whole Matrox Parhelia card issue was just FYI although it runs OpenGL 1.3 everything goes black with a dark red sky. Luckily i have a NVIDI card on wich i normally run Torque so it's no biggie :) but i'll test some more. (it's always good to have it run on everything)
Edit: still black and red...
Back later with more :)
#23
03/09/2006 (4:41 pm)
Hmm, i dont have a Matrox card, so i cant test it here. Any chance you could email me the console log?
#25
It looks like we botched up the DRL-TLK integration. Basically, the terrain is still overbrighting. Here's how to fix that.
1) Comment out #define SG_LIGHTING and #define SG_LIGHTING_TERRAIN_COLOR_CORRECTION in sgLighting.h
2) In sgTerrain::sgRenderBlockDetail() (in sgNewMethods.cc, line 385), comment out #ifdef SG_LIGHTING and #endif
3) For the PC version: in blender_asm.asm, comment out all Lighting Pack Code Blocks (remember to use ; for comments)
For the mac version, find
This should return the terrain back to normal lighting levels, and keep the TLK fix that prevents detail textures from darkening the terrain.
03/11/2006 (1:53 pm)
@EveryoneIt looks like we botched up the DRL-TLK integration. Basically, the terrain is still overbrighting. Here's how to fix that.
1) Comment out #define SG_LIGHTING and #define SG_LIGHTING_TERRAIN_COLOR_CORRECTION in sgLighting.h
2) In sgTerrain::sgRenderBlockDetail() (in sgNewMethods.cc, line 385), comment out #ifdef SG_LIGHTING and #endif
3) For the PC version: in blender_asm.asm, comment out all Lighting Pack Code Blocks (remember to use ; for comments)
For the mac version, find
hscan_component = vec_add(hscan_component, across_component_delta);around line 869, and comment out the Lighting Pack code block after that.
This should return the terrain back to normal lighting levels, and keep the TLK fix that prevents detail textures from darkening the terrain.
#26
Thanks.
03/11/2006 (2:56 pm)
Yeah the fixes do help. I was wondering why the terrain was noticibly brighter looking than my interiors.Thanks.
#27
You guys are doing an awesome job!
-John
03/11/2006 (3:31 pm)
Hi Alex, you guys definitely didn't botch the integration - your resource works great! That assembly code is very easy to miss (I didn't think of it either :).You guys are doing an awesome job!
-John
#28
@Dave: Can you post the specs of your computer? I honestly cannot recreate that bug here. Also, was that happening with the default DRL settings?
@Steven Peterson: In some cases, yes, increasing the y value of setScaleLimits(x, y) won't do anything. This is because the y values sets the maximum scalar. If the DRL code does not need to push up higher, increasing the maximum won't affect anything.
Anyhow, here are some shots of a couple of new things to look forward to. 1) DRL not having issues with dark levels, and 2) exposure blending to keep details in dark areas.
Original code: Note the lack of detail in the shadowed areas.
New code: Here the shadowed areas are far more visible, without altering the rest of the scene.
Original code: Again note the lack of detail in dark areas. A large chunk of the image is totally blacked out. Mac version
New code: Here though we can clearly make out much of the detail that was missing in the original shot. Mac version
Original code: In this shot, we lose almost all of the scene. Also take note of the sharp contrast between areas that are visible and areas completely blacked out.
New code: This shot though has much more visible, and the lighting now gradually tapers off instead of suddenly dropping to black.
And these shots are because I like sharing:
img91.imageshack.us/img91/1588/screenshot002000081uz.jpg
img141.imageshack.us/img141/8523/screenshot002000073ci.jpg
img472.imageshack.us/img472/7632/screenshot002000010vp.png
edit: This code is rather gamma sensitive as I've found out. Your results may vary with these screenshots. I've provided PC and Mac versions for a couple of screenshots, based on the default gamma for the two platforms (2.2 and 1.8 respectively). If your display gamma varies significantly... ya. They won't look so good.
03/11/2006 (4:02 pm)
@John - The assembly code is easy to miss, yes. But 1) A bug is a bug afterall, and 2) We really should've spotted that sooner. Jeff was even complaining about how he couldn't get the sand texture to look right with DRL.@Dave: Can you post the specs of your computer? I honestly cannot recreate that bug here. Also, was that happening with the default DRL settings?
@Steven Peterson: In some cases, yes, increasing the y value of setScaleLimits(x, y) won't do anything. This is because the y values sets the maximum scalar. If the DRL code does not need to push up higher, increasing the maximum won't affect anything.
Anyhow, here are some shots of a couple of new things to look forward to. 1) DRL not having issues with dark levels, and 2) exposure blending to keep details in dark areas.
Original code: Note the lack of detail in the shadowed areas.
New code: Here the shadowed areas are far more visible, without altering the rest of the scene.
Original code: Again note the lack of detail in dark areas. A large chunk of the image is totally blacked out. Mac version
New code: Here though we can clearly make out much of the detail that was missing in the original shot. Mac version
Original code: In this shot, we lose almost all of the scene. Also take note of the sharp contrast between areas that are visible and areas completely blacked out.
New code: This shot though has much more visible, and the lighting now gradually tapers off instead of suddenly dropping to black.
And these shots are because I like sharing:
img91.imageshack.us/img91/1588/screenshot002000081uz.jpg
img141.imageshack.us/img141/8523/screenshot002000073ci.jpg
img472.imageshack.us/img472/7632/screenshot002000010vp.png
edit: This code is rather gamma sensitive as I've found out. Your results may vary with these screenshots. I've provided PC and Mac versions for a couple of screenshots, based on the default gamma for the two platforms (2.2 and 1.8 respectively). If your display gamma varies significantly... ya. They won't look so good.
#29
This is happening on two different comps.
1) P2.2Ghz, 2GB RAM, XP Pro, Radeon K550 128MB
2) P3.2GHz, 1GB Ram, XP Pro, ATI 256MB Card.
If I do the fullscreen filter, the left side does not blend to white.
03/12/2006 (9:53 am)
Yes, default settings!This is happening on two different comps.
1) P2.2Ghz, 2GB RAM, XP Pro, Radeon K550 128MB
2) P3.2GHz, 1GB Ram, XP Pro, ATI 256MB Card.
If I do the fullscreen filter, the left side does not blend to white.
#30
Once again a wonderful resource. Thanks for all the hard work. Wanted to mention something that was happening to me with this, since I hadn't notice anyone else with this particular issue. Everything seems to be working right, and I seem to be getting all the settings tweeked for daylight, indoors and night (though night seems to be the greatest challenge). What is happening is that when I take a screenshot, it goes allmost completely white and then just hangs that way. The game is still running, it just never seems to compensate back. I've included links to two consecutive screenshots to give you an idea on what's happening. Nothng desperate, and could be hardware related ( I have a really wimpy integrated intel 900(?) video card ).
www.reallyreallygoodthings.com/screensfull/screenshot_DRL1.jpg
www.reallyreallygoodthings.com/screensfull/screenshot_DRL2.jpg
Thanks again!
- Alan
Really Really Good Things Studio
03/12/2006 (7:50 pm)
@Alex & JeffOnce again a wonderful resource. Thanks for all the hard work. Wanted to mention something that was happening to me with this, since I hadn't notice anyone else with this particular issue. Everything seems to be working right, and I seem to be getting all the settings tweeked for daylight, indoors and night (though night seems to be the greatest challenge). What is happening is that when I take a screenshot, it goes allmost completely white and then just hangs that way. The game is still running, it just never seems to compensate back. I've included links to two consecutive screenshots to give you an idea on what's happening. Nothng desperate, and could be hardware related ( I have a really wimpy integrated intel 900(?) video card ).
www.reallyreallygoodthings.com/screensfull/screenshot_DRL1.jpg
www.reallyreallygoodthings.com/screensfull/screenshot_DRL2.jpg
Thanks again!
- Alan
Really Really Good Things Studio
#31
edit: That first screenshot looks awesome. Have anymore? I'm a bit of a screenshot addict.
03/12/2006 (9:37 pm)
@Alan: No guarantees that this is it, but this looks like a bug that should be fixed anyways. In game.cc, around line 54, you should see the screenshot consoleFunction. At the very end of that, add glReadBuffer(GL_BACK); It looks like the screenshot function changes the read buffer to the front and doesn't change it back, which is very bad.edit: That first screenshot looks awesome. Have anymore? I'm a bit of a screenshot addict.
#32
That was it. I probably didn't notice it before, because it actually was that way with the Motion Blur Resource integrated, but I recently removed/commented that resource out (It has a pretty hard frame rate hit, though it's really cool). Heres a folder that has a some screenshots with the DRL integrated. Not great shots, but there are a few of them!
www.reallyreallygoodthings.com/screens/DRL/
There are a few more from "Code Name: Monster Island" on our web site also.
Thanks Alex,
- Alan
Really Really Good Things Studio
P.S. Would this effect transparent .difs? I was just noticing that my transparent difs seem to not be working. I don't think I've done anything else, just thought I'd ask while I'm at it. Ran winmerge against the two different build directories but didn't see anything that stood out.
03/12/2006 (10:57 pm)
@AlexThat was it. I probably didn't notice it before, because it actually was that way with the Motion Blur Resource integrated, but I recently removed/commented that resource out (It has a pretty hard frame rate hit, though it's really cool). Heres a folder that has a some screenshots with the DRL integrated. Not great shots, but there are a few of them!
www.reallyreallygoodthings.com/screens/DRL/
There are a few more from "Code Name: Monster Island" on our web site also.
Thanks Alex,
- Alan
Really Really Good Things Studio
P.S. Would this effect transparent .difs? I was just noticing that my transparent difs seem to not be working. I don't think I've done anything else, just thought I'd ask while I'm at it. Ran winmerge against the two different build directories but didn't see anything that stood out.
#33
03/15/2006 (12:22 am)
@Alan: The DRL effect on it's own shouldn't affect transparent .difs (ah, the joys of post-processing). I'm also pretty sure that our TLK integration doesn't change anything other than the vibrant lighting. I'll double check though. 
#34
03/15/2006 (4:42 pm)
This is looking great, guys.
#35
Added some exterior screenshots to the DRL directory, they're the ones in the 89 series range. Realized I only had one exterior shot previously. (Far Cry eat your heart out! =P LOL)
In regards to the transparent .difs, if I take my build directory that they worked in but didn't have the DRL integrated, duplicate it then integrate the resource they stop being transparent. I've poured over the files to try and figure out what it might be, but I have no coding skills, bowstaff skills yes, coding no. Anyway, it's probably something I'm doing wrong (it usually is!).
- Alan
03/15/2006 (8:11 pm)
@Alex,Added some exterior screenshots to the DRL directory, they're the ones in the 89 series range. Realized I only had one exterior shot previously. (Far Cry eat your heart out! =P LOL)
In regards to the transparent .difs, if I take my build directory that they worked in but didn't have the DRL integrated, duplicate it then integrate the resource they stop being transparent. I've poured over the files to try and figure out what it might be, but I have no coding skills, bowstaff skills yes, coding no. Anyway, it's probably something I'm doing wrong (it usually is!).
- Alan
#36
All modifications are in sgInterior.cc
In function void sgInterior::sgRenderARBFCBegin() (line 410) comment out #ifdef SG_LIGHTING and both glTexEnvf(GL_TEXTURE_ENV,GL_RGB_SCALE_EXT, SG_LIGHTING_OVERBRIGHT_AMOUNT); \ and the final #endif.
Do the same thing in function void sgInterior::sgRenderVCFCBegin() Again, be sure to comment out both lines that overbright the texture.
That should do the trick. No guarantees though.
03/15/2006 (10:29 pm)
@Alan: I took a look. Sure enough, commenting out #define SG_LIGHTING disables transparent interiors. This might fix it. I have no transparent interiors to test with, so...All modifications are in sgInterior.cc
In function void sgInterior::sgRenderARBFCBegin() (line 410) comment out #ifdef SG_LIGHTING and both glTexEnvf(GL_TEXTURE_ENV,GL_RGB_SCALE_EXT, SG_LIGHTING_OVERBRIGHT_AMOUNT); \ and the final #endif.
Do the same thing in function void sgInterior::sgRenderVCFCBegin() Again, be sure to comment out both lines that overbright the texture.
That should do the trick. No guarantees though.
#37
Yep, that did the trick! Thanks once again for a great resource and followup.
- Alan
03/15/2006 (11:13 pm)
@Alex,Yep, that did the trick! Thanks once again for a great resource and followup.
- Alan
#38
does anyone know if this will plug easily into TGE1.3 / TLK1.3.5 ?
cheers,
Orion
03/16/2006 (3:18 pm)
hi all -does anyone know if this will plug easily into TGE1.3 / TLK1.3.5 ?
cheers,
Orion
#39
@Alan: I'm glad everything worked out. At this rate though, we're going to need a little TLK integration guide as part of the download. So many things that need minor tweaking, and the list just keeps growing.
03/16/2006 (4:11 pm)
@Orion: Yes, this will plug easily into TGE 1.3 / TLK 1.3.5. You can't just copy over your current files, but if you integrate the specified sections of code, it'll work perfectly with no modifications.@Alan: I'm glad everything worked out. At this rate though, we're going to need a little TLK integration guide as part of the download. So many things that need minor tweaking, and the list just keeps growing.
#40
In my game my projectiles emit a rather large blue light. This appears as it always did for interiors but as soon as the light gets cast on to the terrain the once blue light turns into an overbright white light.
Any ideas?
- Eric
03/16/2006 (5:26 pm)
I think I've found a bug.In my game my projectiles emit a rather large blue light. This appears as it always did for interiors but as soon as the light gets cast on to the terrain the once blue light turns into an overbright white light.
Any ideas?
- Eric
Torque Owner Steven Peterson
It is my observation that in using "setScaleLimits(x, y) the 'y' value only has an effect between 0 and 2. I can tell the difference between 1.9 and 2.0, but not the difference between 2.0 and 10.0 in that range.
Has anyone else noticed this?
[edit] actually the top number might be less than 2. not sure.[/edit]