Dynamic Range Lighting 2.0
by Alex Scarborough · 04/14/2006 (9:33 am) · 90 comments
Download Code File
This resource adds Dynamic Range Lighting 2.0 to the TLK. Even if you already have the original DRL resource, it is suggested that you download and use this instead. It includes a lot of improvements and fixes beyond the addition of exposure blending.
Really, everything is described here so there isn't much to say.
All of the changed TLK files have been included to make integration a breeze. All files are sorted by directory too. It's really all quite straight forward. Just copy over the files and do a clean build.
Read the readme! It'll help get you started. Then go through the rest of the documentation. It's there to help you. Also, download the executables (Mac PC) and take a look at how the various DRL values are working together. The actual values are listed in Using DRL2.0 for easy reference.
In short: copy, paste, compile, and enjoy!
-Alex "Delerium" Scarborough
-Jeff "Reno" Raab
This resource adds Dynamic Range Lighting 2.0 to the TLK. Even if you already have the original DRL resource, it is suggested that you download and use this instead. It includes a lot of improvements and fixes beyond the addition of exposure blending.
Really, everything is described here so there isn't much to say.
All of the changed TLK files have been included to make integration a breeze. All files are sorted by directory too. It's really all quite straight forward. Just copy over the files and do a clean build.
Read the readme! It'll help get you started. Then go through the rest of the documentation. It's there to help you. Also, download the executables (Mac PC) and take a look at how the various DRL values are working together. The actual values are listed in Using DRL2.0 for easy reference.
In short: copy, paste, compile, and enjoy!
-Alex "Delerium" Scarborough
-Jeff "Reno" Raab
About the author
#2
Great job on this guys, really love it.
[Ishbuu]
04/13/2006 (9:56 pm)
Side note, screenshots are very very broken :) But hey, nothing's perfect ;)Great job on this guys, really love it.
[Ishbuu]
#3
And if you've got any you'd like put into the album, let us know.
04/13/2006 (10:03 pm)
Broken screenshots?And if you've got any you'd like put into the album, let us know.
#4
I'll pull up some screenshots when I poke my texture artist to make something other than big blobs of placeholder (yay whoo for being cheap!)
Screenshots break for me, pressing ctrl p seems to take a screenshot, but after that it starts to bug out, gui is the only thing thats updated (say i was looking at a player, and then i moved, the name would be drawn in a big line from where he originally was on my screen) and the only way to fix it is to restart the game. Hardware: Dual 6800 in sli, x2 3800+ @ 2.6ghz (stable), 1gb ram. Doesn't seem like a very contreversial rig to me, all the dual core drivers are in place and tge runs normally, strange eh?
[Ishbuu]
04/13/2006 (11:51 pm)
Heh, the stuff is quite brilliant ;)I'll pull up some screenshots when I poke my texture artist to make something other than big blobs of placeholder (yay whoo for being cheap!)
Screenshots break for me, pressing ctrl p seems to take a screenshot, but after that it starts to bug out, gui is the only thing thats updated (say i was looking at a player, and then i moved, the name would be drawn in a big line from where he originally was on my screen) and the only way to fix it is to restart the game. Hardware: Dual 6800 in sli, x2 3800+ @ 2.6ghz (stable), 1gb ram. Doesn't seem like a very contreversial rig to me, all the dual core drivers are in place and tge runs normally, strange eh?
[Ishbuu]
#5
Right. game.cc, line 54:
At the end of that function, after
That should fix the screenshot issue.
04/13/2006 (11:59 pm)
@Ishbuu: Oh... I forgot a file... Umm... oops? It's a known and fixed issue. It's actually a TGE "bug" of sorts that needs to be fixed.Right. game.cc, line 54:
ConsoleFunction(screenShot, void, 3, 3, "(string file, string format)"
At the end of that function, after
delete bitmap;add
//-----------------------------------------------
// DRL code block begin
//-----------------------------------------------
glReadBuffer(GL_BACK); // Screenshot function needs to reset this.
//-----------------------------------------------
// DRL code block end
//-----------------------------------------------That should fix the screenshot issue.
#6
i'm running a nvidia 7800GS, and running both the example games & my own implementation of the TLK with DRL, the mission editor looks like this: www.irombu.com/drl.problem.png - notice the ghosting of the top menu bar and all the objects ingame...
if i enter ye old optimizeDRL(true); into console, the problem goes away... seems to be very odd though, as my graphics card can more than handle the drl :/
any ideas?
04/14/2006 (12:06 am)
very nice ingame ;) just one issue though - kinda weird :/i'm running a nvidia 7800GS, and running both the example games & my own implementation of the TLK with DRL, the mission editor looks like this: www.irombu.com/drl.problem.png - notice the ghosting of the top menu bar and all the objects ingame...
if i enter ye old optimizeDRL(true); into console, the problem goes away... seems to be very odd though, as my graphics card can more than handle the drl :/
any ideas?
#7
"Call optimizeDRL(true); before entering the world editor. It is also advised that you call setChangeRates(0.0, 0.0); . Having the bloom and exposure blending active will cause issues with the world editor. Also, having the editor active causes DRL to see the scene as brighter than it really is and darken it. By setting the change rates to 0, you lock in the current scale and bias values."
And that screenshot is exactly why you want to call optimizeDRL(true);
edit: Ya, you already found that optimizeDRL(true); fixes it. Basically, there's some sort of major issue with how the world editor works and how DRL works. optimizeDRL(true); is the hack fix that makes editing stuff possible. This should have been listed under Known Issues.
04/14/2006 (12:08 am)
@Gavin: Read the doco. This is listed under General Tips."Call optimizeDRL(true); before entering the world editor. It is also advised that you call setChangeRates(0.0, 0.0); . Having the bloom and exposure blending active will cause issues with the world editor. Also, having the editor active causes DRL to see the scene as brighter than it really is and darken it. By setting the change rates to 0, you lock in the current scale and bias values."
And that screenshot is exactly why you want to call optimizeDRL(true);
edit: Ya, you already found that optimizeDRL(true); fixes it. Basically, there's some sort of major issue with how the world editor works and how DRL works. optimizeDRL(true); is the hack fix that makes editing stuff possible. This should have been listed under Known Issues.
#8
for anyone else trying to work that out, you can just put this into the \creator\editor\EditorGui.cs file
04/14/2006 (12:10 am)
mmm manuals lol thanks :)for anyone else trying to work that out, you can just put this into the \creator\editor\EditorGui.cs file
function EditorGui::onWake(%this)
{
[b]optimizeDRL(true);[/b]
MoveMap.push();
EditorMap.push();
%this.setEditor(%this.currentEditor);
if (DemoEditorAlert.helpTag<2) Canvas.pushDialog(DemoEditorAlert);
}
function EditorGui::onSleep(%this)
{
EditorMap.pop();
MoveMap.pop();
[b]optimizeDRL(false);
resetDRL();[/b]
$Server::CurrentScene.open();
}
#9
Heh, resource isn't even officially "released" yet (ie, it isn't on the front page) and already people are coming up with bugs and fixes for them. Keep the fixes coming, they're very appreciated.
04/14/2006 (1:08 am)
Thanks Gavin!Heh, resource isn't even officially "released" yet (ie, it isn't on the front page) and already people are coming up with bugs and fixes for them. Keep the fixes coming, they're very appreciated.
#10
At least this means that they're happy with the idea and want to make it better :D
Indeed, keep it up guys.
(And we demand more screens. For uh.....making sure it works....yeah that :p )
04/14/2006 (6:55 pm)
Man, i'm not monotoring this every second and come back and see people bug fixing this : pAt least this means that they're happy with the idea and want to make it better :D
Indeed, keep it up guys.
(And we demand more screens. For uh.....making sure it works....yeah that :p )
#11
04/15/2006 (5:56 pm)
Excellent work Alex and James :)
#12
04/16/2006 (11:54 am)
I might have a bug, maybe I missed reading something. When I start a mission and exit it later, then go back into it from the MainMenu again, the area seems very overexposed. I can provide some screenshots if need be. It hasn't happened everytime but sometimes it has.
#13
04/16/2006 (7:03 pm)
@Matt H: That's odd. It should be reseting the scale and bias before mission load. Screenshots would be useful, yes.
#14
Fix here
Some issues with checking for rectangular textures and then doing the right thing with the bloom if they aren't supported. Windows or Linux computers with non-nVidia cards or cards that didn't support rectangular textures were affected. This fixes that issue. It includes new copies of SceneState.cc, WinGL.cc, and x86UNIXGL.cc. The only function changed in SceneState.cc was SceneState::renderBloom(). In WinGL.cc and x86UNIXGL.cc the check for rectangular textures has been modified.
Thanks to Alan James and Eric Hartman for finding and reporting this bug.
04/17/2006 (4:24 pm)
BUG FIXFix here
Some issues with checking for rectangular textures and then doing the right thing with the bloom if they aren't supported. Windows or Linux computers with non-nVidia cards or cards that didn't support rectangular textures were affected. This fixes that issue. It includes new copies of SceneState.cc, WinGL.cc, and x86UNIXGL.cc. The only function changed in SceneState.cc was SceneState::renderBloom(). In WinGL.cc and x86UNIXGL.cc the check for rectangular textures has been modified.
Thanks to Alan James and Eric Hartman for finding and reporting this bug.
#15
I'm seeing some weird behavior:
On the right you can the DRL code doing some odd things to the terrain texture, while the left shows the texture as it appears with the stock TLK. This happens even with DRL(false);
Any ideas on what might cause this behavior?
04/18/2006 (7:05 pm)
First off - I love this resource. Thanks very much for making it available.I'm seeing some weird behavior:
On the right you can the DRL code doing some odd things to the terrain texture, while the left shows the texture as it appears with the stock TLK. This happens even with DRL(false);
Any ideas on what might cause this behavior?
#16
04/18/2006 (7:41 pm)
@Jody: Is the problem still present if you call DRL(false); before loading any missions? Because... wow, I've never seen DRL do anything like that. That isn't just some color change stuff, it looks like it's completely messing up the texturing.
#17
04/19/2006 (5:26 am)
@Alex: Yep, still happens. Very strange. All I've done is drop in the binaries built with DRL into the Dungeon Pack example mission.
#18
04/20/2006 (5:49 am)
Looks like some kind of GL setting is leaking onto the terrain rendering. Did you try calling dglSetCAnonicalState() after the DRL rendering?
#19
I've got a day/night system going, every few hours I call function that does all the drl settings, based on an array I wrote. IE, around noon its all set for the manuals suggested day mission settings, and nighttime uses the night settings. I split the difference a few times to make settings for other hours.
Problem is, the function needs (or seems to) to call resetDRL() after making these changes. The reset call causes a quick 'Flash', almost like a lightning bolt would.
In case someone can do this better, here's what I'm using:
And an example setting....
04/24/2006 (4:47 pm)
Is there a way to "quietly" resetDRL()? I've got a day/night system going, every few hours I call function that does all the drl settings, based on an array I wrote. IE, around noon its all set for the manuals suggested day mission settings, and nighttime uses the night settings. I split the difference a few times to make settings for other hours.
Problem is, the function needs (or seems to) to call resetDRL() after making these changes. The reset call causes a quick 'Flash', almost like a lightning bolt would.
In case someone can do this better, here's what I'm using:
//-----------------------------------------------------------------------------
// DRL adjustments
// Currently only called by time(), we should also be calling this from other
// places, with differing light values. Say 1/2 light underwater, 0 light in a
// cave, etc.
//-----------------------------------------------------------------------------
function AdjustDRL(%sunlight)
{
resetDRL();
setGoalIntensity($goalIntensity[%sunlight]);
setUnderexposureIntercept($underexposureIntercept[%sunlight]);
setUnderexposureWhiteOffset($underexposureWhiteOffset[%sunlight]);
setUnderexposureIntercept($underexposureIntercept[%sunlight]);
error("***DRL lighting set to intensity " @ %sunlight);
}And an example setting....
$goalIntensity[0] = 0.05; // darkest, night, caverns $underexposureIntercept[0] = 0.09; $underexposureWhiteOffset[0] = 0.03; $underexposureIntercept[0] = 0.1;
#20
04/24/2006 (6:50 pm)
@Erik: What you might want to try is writing another resetDRL console function that only resets the scale and bias and not the textures. That flash is probably caused by a couple of very slow frames as DRL recreates the six-seven massive textures it uses. 
Torque 3D Owner iHugMedia