Prerendering and selecting Lightmaps for Time of Day system
by Henry Todd · in Torque Game Engine · 05/29/2007 (7:15 pm) · 6 replies
This has been on my List(tm) for about a year now, and I'm actually only a few items away from just trying to work it out on my own, but I thought I'd see if anyone had already explored this before spending too much time on it.
Okay, so here's the basic idea:
There are already plenty of great resources for creating a time of day system, at least in terms of moving the sun object and changing the world lighting/sky params to fit the time, however none of these will really work well with the pre-baked lighting used on terrain and interiors.
The solution to this seems obvious to me: Pre-render lighting states for each time of day and swap between them as needed, instead of having the client relight the scene whenever it wants to. In other words, each mission will have at least a "day" and "night lightmap, but more realistically, there will be 1 for every hour of game time.
Now, the actual question:
As I see it, there are only 3 things which need to be done here:
1) Disabling the automatic lighting of the scene on load.
2) Forcing the loading of a specific lightmap by filename (*.ml files) via script without forcing the client to reload the level.
3) Maintaining the ability to manually relight the scene via Alt-L/Relight Scene button and automatically lighting the scene if no lightmap is specified/available during load.
And I'm basically just wondering if anyone has explored this, specifically how to load a lightmap by filename (it's pretty easy to do #2 by just canceling phase 3 of the mission load). Just a pointer to the correct parts of the code would be enough to get me going.
Okay, so here's the basic idea:
There are already plenty of great resources for creating a time of day system, at least in terms of moving the sun object and changing the world lighting/sky params to fit the time, however none of these will really work well with the pre-baked lighting used on terrain and interiors.
The solution to this seems obvious to me: Pre-render lighting states for each time of day and swap between them as needed, instead of having the client relight the scene whenever it wants to. In other words, each mission will have at least a "day" and "night lightmap, but more realistically, there will be 1 for every hour of game time.
Now, the actual question:
As I see it, there are only 3 things which need to be done here:
1) Disabling the automatic lighting of the scene on load.
2) Forcing the loading of a specific lightmap by filename (*.ml files) via script without forcing the client to reload the level.
3) Maintaining the ability to manually relight the scene via Alt-L/Relight Scene button and automatically lighting the scene if no lightmap is specified/available during load.
And I'm basically just wondering if anyone has explored this, specifically how to load a lightmap by filename (it's pretty easy to do #2 by just canceling phase 3 of the mission load). Just a pointer to the correct parts of the code would be enough to get me going.
About the author
Recent Threads
#2
05/29/2007 (8:29 pm)
I've got to say, this is a pretty good idea. The only flaw with it is that the swapped lightmap will stick out to players. I think a better idea would be to have a fullscreen filter rendered onto everything but the sky. The color of the filter would be based on the sun's position. This wouldn't solve the shadowing problem, but color wise, you'd be good. I've been working on this in TGEA using multipass shaders, but have yet to come out with great results. I'm not exactly sure how lighting works. If lighting/shadowing was based on the client's current zone, you might be able to get away with dynamic lighting.
#3
For my purposes the trade-off of having to pre-bake all of the lightmaps and accept the occasional (1/hour) stutter far outweighs having to either use dynamic lighting only or just not include time of day. For additional smoothness, use smaller increments of time for the lightmap changes, but understand that this means a noticeable pattern of short halts for your players. I prefer 1 hour as it's so infrequent it will likely go unnoticed. Everyone blips at the same time, so it's not going to result in any frozen kills, unless your system is so obsolete that it takes a minute or so to load the lightmaps (386? :D)
You can try this out yourself, at least the cheap way, by simply putting "lightScene();" into the console. Assuming you haven't edited the map since loading, this will just reload the .ml file from the disk, so you can get an idea of how long the "blip" is on your hardware/in your maps. If you decide to make this mod, follow the chain that starts with that console command to SceneLighting::light, which will show you how you load a specific mission file. You'll need to build a custom console function that lights the scene with a specific .ml file, and I have no clue what happens if you pick a file that wasn't built from that version of the map. Bad things, I assume.
A final note on this, anyone who's played Crysis will notice that it uses only dynamic shadows. Obviously, this technology has arrived, and will be common in the next gen of games, but it's not feasible for mid-high current day PCs. On all "very high" settings, I got the demo to average 20 fps at 1280x1024, which is playable but not great, and this is on a 640 mb 8800 GTS.
11/09/2007 (8:47 pm)
I wanted to respond to this thread I started and mention that I did eventually implement a system for dynamically loading lightmaps. I'm pretty happy with it, overall. The loading of a pre-made lightmap takes a little under half a second on a moderately complex map, at least on my system. The client does lock up during the load, but a half second blip every hour isn't critical. Since each lightmap represents an hour of daylight, the jump on each switch is noticeable, assuming you're watching for it, but not jarring. That's the key, though -- to notice it, you have to basically be watching for it, as the light source itself moves and changes color every few seconds. Only the shadows will jump, not the sun or the lighting on weapons/players/vehicles.For my purposes the trade-off of having to pre-bake all of the lightmaps and accept the occasional (1/hour) stutter far outweighs having to either use dynamic lighting only or just not include time of day. For additional smoothness, use smaller increments of time for the lightmap changes, but understand that this means a noticeable pattern of short halts for your players. I prefer 1 hour as it's so infrequent it will likely go unnoticed. Everyone blips at the same time, so it's not going to result in any frozen kills, unless your system is so obsolete that it takes a minute or so to load the lightmaps (386? :D)
You can try this out yourself, at least the cheap way, by simply putting "lightScene();" into the console. Assuming you haven't edited the map since loading, this will just reload the .ml file from the disk, so you can get an idea of how long the "blip" is on your hardware/in your maps. If you decide to make this mod, follow the chain that starts with that console command to SceneLighting::light, which will show you how you load a specific mission file. You'll need to build a custom console function that lights the scene with a specific .ml file, and I have no clue what happens if you pick a file that wasn't built from that version of the map. Bad things, I assume.
A final note on this, anyone who's played Crysis will notice that it uses only dynamic shadows. Obviously, this technology has arrived, and will be common in the next gen of games, but it's not feasible for mid-high current day PCs. On all "very high" settings, I got the demo to average 20 fps at 1280x1024, which is playable but not great, and this is on a 640 mb 8800 GTS.
#4
the users have the bear the hit of downloading the extra lightmaps tho, yeah ?
we're running about 800KB per lightmap, is that what you see ?
11/09/2007 (9:14 pm)
Sounds pretty cool.the users have the bear the hit of downloading the extra lightmaps tho, yeah ?
we're running about 800KB per lightmap, is that what you see ?
#5
If you're concerned about including these with a download, you could set up a script to bake them all at once the first time the map is loaded. That would probably take a good while, especially for a single-player game where the first load is likely to be the only one the player gets. Unfortunately, depending on the hardware, this process could take a long time even if you tried to do it all during installation. At 1 minute per lightmap, 24/map, 10 maps.. well, the process takes about 4 hours. Even at 8/map that's still well over an hour.
In other words, including them is probably more viable, even with the size increase. If it's impossible to make the download that large for your target audience, then consider only using it on a few maps, or only doing solid times of day (day/night/dawn/dusk) with it and blending in between by just moving the sun.
One notable disadvantage I can think of involves procedurally generated maps.. obviously there's no way to pre-make lightmaps for randomly/script-generated maps.
And something I'd like to try: The latest versions of TGEA have pretty good shadow support. I wonder how well it'd perform attempting to use all dynamic shadows like Crysis... I'm guessing "not well," but who knows, it might be suitable for some environments.
11/09/2007 (11:47 pm)
Just looking at my missions directory, I see a range of about 300-900 kb, and many of those are simple maps for testing specific features. I wouldn't be surprised if they were upwards of 1mb each for large production quality maps. You only lose about 10% by putting one of these into a "best" compression RAR. I think you could pretty safely do 2 or 3 hours per light state without it being particularly bad, which would significantly decrease the amount of space taken.If you're concerned about including these with a download, you could set up a script to bake them all at once the first time the map is loaded. That would probably take a good while, especially for a single-player game where the first load is likely to be the only one the player gets. Unfortunately, depending on the hardware, this process could take a long time even if you tried to do it all during installation. At 1 minute per lightmap, 24/map, 10 maps.. well, the process takes about 4 hours. Even at 8/map that's still well over an hour.
In other words, including them is probably more viable, even with the size increase. If it's impossible to make the download that large for your target audience, then consider only using it on a few maps, or only doing solid times of day (day/night/dawn/dusk) with it and blending in between by just moving the sun.
One notable disadvantage I can think of involves procedurally generated maps.. obviously there's no way to pre-make lightmaps for randomly/script-generated maps.
And something I'd like to try: The latest versions of TGEA have pretty good shadow support. I wonder how well it'd perform attempting to use all dynamic shadows like Crysis... I'm guessing "not well," but who knows, it might be suitable for some environments.
#6
The only thing preventing me from releasing my modification as a resource, is an inability to get the sun to move while in game... MainSun.SetFieldValue(elevation, 40) doesn't work for example on my sunobject named MainSun. The variable updates correctly, but the sun doesn't actually move unless I go into the mission editor and click the object bar... I'm missing something simple I bet, but its held me up for over a week already.
Anyways, in RELEASE compile, relighting a single interior with 2 floors and 5 rooms takes about 200ms on 2Ghz computer. I see some ways I might be able to get this down to 100-150ms by breaking it up so chunks get processed in 50ms pieces. Regardless, it isn't noticeable at all. It will be noticeable in DEBUG mode as 5 second updates. So you'll want to comment out the relighting and use gllighting for testing.
I basically have setup a scheduled event that runs every every 10 minutes, and relights a different building every 5 seconds then stops when all the buildings have been updated. Then it finished by updating the terrain lightmap. As long as the time of day isn't changing extremely fast you'll barely notice the changing shadows. More importantly, this lets me relight an interior upon placement! This can be useful for games where dynamic placement or creation of interiors is wanted.
So I dunno.. if I can figure out how people make their sun objects move around via script or console command I'll be able to more fully test my code, and release it for folks :P
11/10/2007 (10:06 pm)
Pre-rendering lightmaps might not be the optimal solution if cludgy hacks are required. All in all, it wasn't too difficult to edit the engine so interiors selectively relight. I did it with very little knowledge of the engine and intermediate skill in C++. So I encourage folks to give it a look at. Just write down all the functions called to relight a scene, and take it one step at a time. The only thing preventing me from releasing my modification as a resource, is an inability to get the sun to move while in game... MainSun.SetFieldValue(elevation, 40) doesn't work for example on my sunobject named MainSun. The variable updates correctly, but the sun doesn't actually move unless I go into the mission editor and click the object bar... I'm missing something simple I bet, but its held me up for over a week already.
Anyways, in RELEASE compile, relighting a single interior with 2 floors and 5 rooms takes about 200ms on 2Ghz computer. I see some ways I might be able to get this down to 100-150ms by breaking it up so chunks get processed in 50ms pieces. Regardless, it isn't noticeable at all. It will be noticeable in DEBUG mode as 5 second updates. So you'll want to comment out the relighting and use gllighting for testing.
I basically have setup a scheduled event that runs every every 10 minutes, and relights a different building every 5 seconds then stops when all the buildings have been updated. Then it finished by updating the terrain lightmap. As long as the time of day isn't changing extremely fast you'll barely notice the changing shadows. More importantly, this lets me relight an interior upon placement! This can be useful for games where dynamic placement or creation of interiors is wanted.
So I dunno.. if I can figure out how people make their sun objects move around via script or console command I'll be able to more fully test my code, and release it for folks :P
Torque Owner Jason Lee
Personally I'd like to help work on this resource if there is dynamic or lightmap lighting, weather generation and time of day all mixed together.