Dynamic Range Lighting - 56k
by Alex Scarborough · 03/29/2006 (10:01 pm) · 15 comments
Well, since I just dumped 53 new screenshots here I should probably talk about what's new and all that jazz. If you don't own the TLK, disregard this blog. Or go buy the TLK and then come back.
Bug Fixes
DRL2.0 features a couple of major bug fixes. First and foremost is a rendering glitch with the bloom effect. In the original DRL resource, having the bloom on would create a white border around the scene. In DRL2.0, the bloom effect will use rectangular textures if available, and if not will at least not tile. So, huzzah there, no more annoying border.
The other major bug fix is in the actual intensity calculations. They tended to be spotty at best (something about going from 3,000 pixels to 12 in a single step). That's been fixed, at a slight performance cost since we're hitting up against a GPU-CPU transfer bottleneck now. Also, the actual reading was completely messed up. With only 12 pixels, it wasn't all that noticeable, but because we now bring in far more pixels, that's been fixed too.
Finally, the modified TLK files will be included in the download, which should make integration very easy.
New Features
Or the bit that everyone really cares about. DRL2.0 introduces one, and only one, brand new feature. DRL2.0 uses a very watered down version of exposure blending. In brief, DRL2.0 generates three different versions of the scene, based on a few script controlled variables. These three different images (overexposed, normal exposure, and underexposed) are then blended together using min/max blending. The difference this makes is huge. For starters, DRL2.0 handles night/dark missions just fine now. No issues whatsoever. No constant blacking out, no loss of contrast in brigther areas, it just works. Observe.
This holds true for all dark areas. With the proper settings, it is entirely possible to keep the dark areas of your mission completely visible without any sacrifice in contrast for the brighter areas of your mission.
That's the overexposure, what about the underexposure? (yes, I know, the names are completely and utterly wrong for how I'm doing this, but they do properly describe what this does). Well... it's subtle. This is a screenshot without underexposure.
img136.imageshack.us/img136/3888/screenshot050000139rd.jpg
Note the areas that are "blown out" by the lights. Basically, any area around the physical lights, the walls to the side of the ligths, and the floor beneath the lights.
Same scene, but with underexposure.
img221.imageshack.us/img221/52/screenshot050000129az.jpg
Look at those same areas. We're still losing some detail, but a lot of it is visible now. More importantly, instead of glare, we now have a soft bloom effect. In fact, underexposure completely saved this next screenshot.
No underexposure
img150.imageshack.us/img150/8766/screenshot048000143du.jpg
Notice that that is just ugly. It hurts to look at.
With underexposure
img150.imageshack.us/img150/751/screenshot048000154wj.jpg
That's better. The sand isn't some garish shade of yellow, white, orange, or red. It has a very soft bloom coming off of it instead of a hard glare. Also, we get fog back. Instead of completely blown out white fog, we get some nice grey fog. And then the completely blown out white fog. But it's a start. The other shots that have been uploaded feature underexposure and overexposure, and a couple feature the effects half-screened so you can clearly see the difference. Or wonder if there really is a difference. It can be subtle at times, but it's there.
Feature that didn't make the cut
My favorite part of movie DVD's are the deleted scenes. Consider this the "deleted scene" of DRL. It sounded cool, it even looked kinda cool, but it just wasn't practical. Night vision. Not the glowy green night vision of night vision goggles, but real human night vision. Black and white, grainy. That kind of night vision.
img523.imageshack.us/img523/7991/screenshot011000027py.jpg
It was a cool idea, but the implementation was iffy at best. It was impossible to figure out when the night vision effect should kick in (please don't suggest "at night"). Also, just getting it to work properly was killer. The graininess was hard to get down just right, and the addition of another texture copy and filter was just too much. And ultimately, it would be a little used feature that just sucked up time to process. Maybe if people actually ask for it, I'll look into doing it right and putting it into the next next release of DRL. Until then, it'll provide some interesting screenshots.
One more thing... or two... or three... just stick with me folks
DRL2.0 will be a TLK only release, just like the original DRL resource. However, we will be publicly releasing DRL2.0 demos for Mac and Windows with three missions, each with carefully set values to proplerly show off DRL2.0. After some initial debate, Jeff and I settled on using the stock TLK demo missions. The original plan was to use a The Third Reich test level, but... umm... it ran at five frames per second without DRL. Adding DRL didn't really help with that. The 150MB download was also an issue. It sure looked nice though.
img138.imageshack.us/img138/3609/screenshot002000033vv.jpg
DRL2.0 will also have better documentation, both in the form of readme's and with source code comments. One of the largest complaints about the original release was the lack of documentation. Since we've just increased the complexity of DRL, better documentation is probably a good idea.
DRL2.0 will also feature an even more drastic drop in FPS. Just wanted to put that out there. Hey, exposure blending is pricy.
So when are you going to release it already?
"Soon". I'm uploading the pics now because I'm cheap, and a free flickr account only gets 20MB of uploads a month, and the month is almost over. And this .plan is because I'd feel bad just uploading pics and not offering any explanation. However, DRL2.0 still needs some testing, and it looks like there are some performance trouble areas that can be worked out. And documentation needs to be written. We're hoping for an early/mid April release though.
But, it'd be mean to just leave you hanging. Here's a set of my favorite pics from the 53 I uploaded.





There you have it. As for system requirements, DRL2.0 really really likes it when your graphics card supports rectangular textures and EXT_blend_minmax. Rectangular textures require Radeon/GeForce 2 or better. EXT_blend_minmax requres a Radeon 8500/GeForce 2 or better. Blame ATi for the bad support, it's an OpenGL 1.2 core feature.
Ooh, almost forgot. I'd like to thank John Kabus for being a generally awesome guy and helping us every step of the way with this. I'd also like to thank Jeff "Reno" Raab for being my co-conspirator in this bid for world domination. And thanks to everyone who put up screenshots of DRL in their games and/or offered feature suggestions. The screenshots were awesome and the feature suggestions spurred on further development. And documentation.
Edit: Hehe... it will be out before Constructor weekend. This is because Constructor weekend will probably be in May, or maybe June. It probably won't be out in time for this upcoming GID, which is the 8th/9th of April.
Bug Fixes
DRL2.0 features a couple of major bug fixes. First and foremost is a rendering glitch with the bloom effect. In the original DRL resource, having the bloom on would create a white border around the scene. In DRL2.0, the bloom effect will use rectangular textures if available, and if not will at least not tile. So, huzzah there, no more annoying border.
The other major bug fix is in the actual intensity calculations. They tended to be spotty at best (something about going from 3,000 pixels to 12 in a single step). That's been fixed, at a slight performance cost since we're hitting up against a GPU-CPU transfer bottleneck now. Also, the actual reading was completely messed up. With only 12 pixels, it wasn't all that noticeable, but because we now bring in far more pixels, that's been fixed too.
Finally, the modified TLK files will be included in the download, which should make integration very easy.
New Features
Or the bit that everyone really cares about. DRL2.0 introduces one, and only one, brand new feature. DRL2.0 uses a very watered down version of exposure blending. In brief, DRL2.0 generates three different versions of the scene, based on a few script controlled variables. These three different images (overexposed, normal exposure, and underexposed) are then blended together using min/max blending. The difference this makes is huge. For starters, DRL2.0 handles night/dark missions just fine now. No issues whatsoever. No constant blacking out, no loss of contrast in brigther areas, it just works. Observe.
This holds true for all dark areas. With the proper settings, it is entirely possible to keep the dark areas of your mission completely visible without any sacrifice in contrast for the brighter areas of your mission.That's the overexposure, what about the underexposure? (yes, I know, the names are completely and utterly wrong for how I'm doing this, but they do properly describe what this does). Well... it's subtle. This is a screenshot without underexposure.
img136.imageshack.us/img136/3888/screenshot050000139rd.jpg
Note the areas that are "blown out" by the lights. Basically, any area around the physical lights, the walls to the side of the ligths, and the floor beneath the lights.
Same scene, but with underexposure.
img221.imageshack.us/img221/52/screenshot050000129az.jpg
Look at those same areas. We're still losing some detail, but a lot of it is visible now. More importantly, instead of glare, we now have a soft bloom effect. In fact, underexposure completely saved this next screenshot.
No underexposure
img150.imageshack.us/img150/8766/screenshot048000143du.jpg
Notice that that is just ugly. It hurts to look at.
With underexposure
img150.imageshack.us/img150/751/screenshot048000154wj.jpg
That's better. The sand isn't some garish shade of yellow, white, orange, or red. It has a very soft bloom coming off of it instead of a hard glare. Also, we get fog back. Instead of completely blown out white fog, we get some nice grey fog. And then the completely blown out white fog. But it's a start. The other shots that have been uploaded feature underexposure and overexposure, and a couple feature the effects half-screened so you can clearly see the difference. Or wonder if there really is a difference. It can be subtle at times, but it's there.
Feature that didn't make the cut
My favorite part of movie DVD's are the deleted scenes. Consider this the "deleted scene" of DRL. It sounded cool, it even looked kinda cool, but it just wasn't practical. Night vision. Not the glowy green night vision of night vision goggles, but real human night vision. Black and white, grainy. That kind of night vision.
img523.imageshack.us/img523/7991/screenshot011000027py.jpg
It was a cool idea, but the implementation was iffy at best. It was impossible to figure out when the night vision effect should kick in (please don't suggest "at night"). Also, just getting it to work properly was killer. The graininess was hard to get down just right, and the addition of another texture copy and filter was just too much. And ultimately, it would be a little used feature that just sucked up time to process. Maybe if people actually ask for it, I'll look into doing it right and putting it into the next next release of DRL. Until then, it'll provide some interesting screenshots.
One more thing... or two... or three... just stick with me folks
DRL2.0 will be a TLK only release, just like the original DRL resource. However, we will be publicly releasing DRL2.0 demos for Mac and Windows with three missions, each with carefully set values to proplerly show off DRL2.0. After some initial debate, Jeff and I settled on using the stock TLK demo missions. The original plan was to use a The Third Reich test level, but... umm... it ran at five frames per second without DRL. Adding DRL didn't really help with that. The 150MB download was also an issue. It sure looked nice though.
img138.imageshack.us/img138/3609/screenshot002000033vv.jpg
DRL2.0 will also have better documentation, both in the form of readme's and with source code comments. One of the largest complaints about the original release was the lack of documentation. Since we've just increased the complexity of DRL, better documentation is probably a good idea.
DRL2.0 will also feature an even more drastic drop in FPS. Just wanted to put that out there. Hey, exposure blending is pricy.
So when are you going to release it already?
"Soon". I'm uploading the pics now because I'm cheap, and a free flickr account only gets 20MB of uploads a month, and the month is almost over. And this .plan is because I'd feel bad just uploading pics and not offering any explanation. However, DRL2.0 still needs some testing, and it looks like there are some performance trouble areas that can be worked out. And documentation needs to be written. We're hoping for an early/mid April release though.
But, it'd be mean to just leave you hanging. Here's a set of my favorite pics from the 53 I uploaded.





There you have it. As for system requirements, DRL2.0 really really likes it when your graphics card supports rectangular textures and EXT_blend_minmax. Rectangular textures require Radeon/GeForce 2 or better. EXT_blend_minmax requres a Radeon 8500/GeForce 2 or better. Blame ATi for the bad support, it's an OpenGL 1.2 core feature.
Ooh, almost forgot. I'd like to thank John Kabus for being a generally awesome guy and helping us every step of the way with this. I'd also like to thank Jeff "Reno" Raab for being my co-conspirator in this bid for world domination. And thanks to everyone who put up screenshots of DRL in their games and/or offered feature suggestions. The screenshots were awesome and the feature suggestions spurred on further development. And documentation.
Edit: Hehe... it will be out before Constructor weekend. This is because Constructor weekend will probably be in May, or maybe June. It probably won't be out in time for this upcoming GID, which is the 8th/9th of April.
About the author
#2
03/30/2006 (1:10 am)
Constructor Weekend?
#3
http://www.garagegames.com/mg/snapshot/view.php?qid=1162
:)
03/30/2006 (2:34 am)
"Constructor Weekend?"http://www.garagegames.com/mg/snapshot/view.php?qid=1162
:)
#4
03/30/2006 (5:29 am)
Those are some great pics. Makes me glad I got TLK. Can't wait for this.
#5
03/30/2006 (7:21 am)
This looks great. Amazing Work!
#6
03/30/2006 (8:28 am)
I haven't looked at it closely, but is there a way to turn DRL off at the client (like as an option) if performance suffers too much?
#7
03/30/2006 (8:33 am)
Well, there's a hackish way that pretty much kills it. But there isn't a dedicated on/off switch. I'll add one to DRL2.0. However, chances are that if you're willing to sacrifice all the pretty effects, like bloom and the upcoming exposure blending, you can have DRL with very minimal performance impact.
#8
The dynamic tonemaping(apature adjustment) currently cant be turned off, but things like bloom can be, and a delay can be added between checks to save on performance.
We wanted, if at all possible, to make DRL a 'nessicary' feature, so if it was added, we wouldnt have what happened with DoD, where if you played offline, you'd have it on, but online everyone turns it off.
With it as a always-on feature to some degree, you can make it part of the game's dynamics(fun thing to ad to the feature list, eh?)so for FPS', flashbangs would really do their jobs, shooting lights out would temporarily disorient opponents making it capable of you striking, etc.
Obviously for games like RTS it would be as critical(and at that point, you could probably get a turn-it-all-off option), but for games like FPS, and the like, having it always on in a fashion can add to gameplay.
Starting to rant :p
better cut off there hehe
03/30/2006 (8:36 am)
There is an setup that will turn features off, yes.The dynamic tonemaping(apature adjustment) currently cant be turned off, but things like bloom can be, and a delay can be added between checks to save on performance.
We wanted, if at all possible, to make DRL a 'nessicary' feature, so if it was added, we wouldnt have what happened with DoD, where if you played offline, you'd have it on, but online everyone turns it off.
With it as a always-on feature to some degree, you can make it part of the game's dynamics(fun thing to ad to the feature list, eh?)so for FPS', flashbangs would really do their jobs, shooting lights out would temporarily disorient opponents making it capable of you striking, etc.
Obviously for games like RTS it would be as critical(and at that point, you could probably get a turn-it-all-off option), but for games like FPS, and the like, having it always on in a fashion can add to gameplay.
Starting to rant :p
better cut off there hehe
#9
03/30/2006 (10:24 am)
love the pics
#10
However, for a single player game it would be nice to turn off options as a player in the gui's options window for performance reasons.
03/30/2006 (11:56 am)
You make sense Jeff. I like playing with all the bells and whistles even though I'm at a disadvantage against those who turn the stuff off.However, for a single player game it would be nice to turn off options as a player in the gui's options window for performance reasons.
#11
03/30/2006 (12:33 pm)
@Alan...that's what I'm getting at. I'm working on a single-player game, so it would be nice to have that option if performance takes a nice hit. But I do agree that DRL can really add to the experience, and for multiplayer games it can result in some disadvantages.
#12
Will you make a "resource" version available like last time, so we can hack it into existing TLK projects? Thanks!
03/30/2006 (12:52 pm)
Seems like you guys learned a lot from the first time around! Actually, I know I did just watching it. I can't wait to give this a try now!!! :-) Will you make a "resource" version available like last time, so we can hack it into existing TLK projects? Thanks!
#13
The source code will be relased as a community resource. The downloadable executables are to show people who don't own the TLK what they're missing out on, and also to show how flexible and easy to set up it is. I'll also probably write a quick tutorial based on the example missions on how to choose the proper settings for your mission and have them set on mission load.
03/30/2006 (1:11 pm)
@Steven "Raven" PetersonThe source code will be relased as a community resource. The downloadable executables are to show people who don't own the TLK what they're missing out on, and also to show how flexible and easy to set up it is. I'll also probably write a quick tutorial based on the example missions on how to choose the proper settings for your mission and have them set on mission load.
#14
03/30/2006 (2:28 pm)
Thanks. Looking forward to it!
#15
Loved to see a multiplayer sneak-em-up with night vision, hiding by not moving and stuff.
(Well I love to see a multplayer sneak-em-up that work at all, i guess ;-)
Or better even, love to make one :-)
Thanks for all your good work!
04/14/2006 (1:19 am)
Love the night vision idea! That's the kind of thing that puches the envelope of realism/style.Loved to see a multiplayer sneak-em-up with night vision, hiding by not moving and stuff.
(Well I love to see a multplayer sneak-em-up that work at all, i guess ;-)
Or better even, love to make one :-)
Thanks for all your good work!
Torque Owner Jeff "Reno" Raab
[ghc]games
Nothing more to say