Moving Sun... Moving Shadows?
by Craig Fortune · in Torque Game Engine · 02/27/2004 (10:57 am) · 21 replies
I thought this will probably be the best place to start a thread like this, but possibly might move it into the private area of the forums (SDK owners) if we need to start about the inner workings etc.
First off i'm not a programmer, so chat about the principals, not the code to me ;) (Although programmer on team will probably be on this thread soon enough)
Problem is thus:
I'm involved in an MMORPG using torque thats going really well. We have a skills system and a persistant world starting to form, we are starting to work on quests etc. Anywho, onto the main body of this post.
We have hit a rather annoying stumbling block as the title implies. We want to have day/night cycles, which requires a moving sun. Now changing the brightness is not a problem, HOWEVER, changing where the shadows are is a problem. We cant see a way to do this, as its ovbiously completely impossible to re-calc the lightmap every frame =D
Has anyone got any ideas? We have been thinking of vertex shaders, but then this even stops some of the team working on the game let alone the possible players...
I know this is kind of trying to force a debate from the community to suit our own needs, but well, I'm almost certain theres other people out there having this problem. Thus, they will hopefully benefit from it!
First off i'm not a programmer, so chat about the principals, not the code to me ;) (Although programmer on team will probably be on this thread soon enough)
Problem is thus:
I'm involved in an MMORPG using torque thats going really well. We have a skills system and a persistant world starting to form, we are starting to work on quests etc. Anywho, onto the main body of this post.
We have hit a rather annoying stumbling block as the title implies. We want to have day/night cycles, which requires a moving sun. Now changing the brightness is not a problem, HOWEVER, changing where the shadows are is a problem. We cant see a way to do this, as its ovbiously completely impossible to re-calc the lightmap every frame =D
Has anyone got any ideas? We have been thinking of vertex shaders, but then this even stops some of the team working on the game let alone the possible players...
I know this is kind of trying to force a debate from the community to suit our own needs, but well, I'm almost certain theres other people out there having this problem. Thus, they will hopefully benefit from it!
#2
anyway i think Craig is asking for some ideas about interiors casting dynamic shadows. I think that when you press alt-l you call relightScene() or something like that, forcing a recalculation of the lightmaps and it takes a lot of time, so it can't be done every frame, and not even once every 1000 frames, it can be done only at game start.
Do you think it would be possible to have interiors cast shadows like dts shapes do, or would it slow down things too much? if it's at all possible, what could be a reasonable way of doing it?
02/27/2004 (12:12 pm)
Britton: that would certainly work in mission editor mode...anyway i think Craig is asking for some ideas about interiors casting dynamic shadows. I think that when you press alt-l you call relightScene() or something like that, forcing a recalculation of the lightmaps and it takes a lot of time, so it can't be done every frame, and not even once every 1000 frames, it can be done only at game start.
Do you think it would be possible to have interiors cast shadows like dts shapes do, or would it slow down things too much? if it's at all possible, what could be a reasonable way of doing it?
#3
02/27/2004 (1:15 pm)
I thought about trying this a little while ago and my first reaction was (someone hit me if I'm way off base -- I haven't actually spent the time to look if this is feasible) to hack the lightmap code so that it uses pregenerated lightmaps instead of looking at the mission checksum. It would then be a matter of building a number of lightmaps for diffrent times of day and loading the appropriate ones to fade between. My feeling is that you'll have a much better chance of getting decent performance than using real shadows for buildings (also given that the current shadow implementation doesn't self-shadow or shadow other dts objects to my knowledge).
#4
Any more thoughts on this?
02/27/2004 (1:31 pm)
We have discussed the fading between different shadows idea but we wondered what it would actually look like in practise. Maybe we should try it and see what happens?Any more thoughts on this?
#5
02/27/2004 (2:25 pm)
You could always try going to stencil shadows for everything/most everything... It could be pretty fast if you choose a method that lets you keep everything for static objects in static vertex buffers.
#7
02/27/2004 (3:08 pm)
Did you look at Joshua Ritter's day/night code? Look for it in http://www.actionrpg.com
#8
This is an idea I came up with for calculating various things in my project. Just steal a few cycles to do your calcs and return to the main program.
02/27/2004 (3:15 pm)
I'm not a C++ programmer and don't know the inner workings of the engine, but maybe you could recalculate shadows and lighting piece-by-piece over a set time interval. Lets say you have 16 hours of light (counting dawn and dusk low light levels). You would need 16 different shadow positions and lighting values. Now lets say that you will run the game at 4x real time, making a game day six hours of real time. This means that you would have 22.5 minutes (6 hours x 60 minutes / 16 game hours) to calculate the new shadows and lighting a piece at a time.This is an idea I came up with for calculating various things in my project. Just steal a few cycles to do your calcs and return to the main program.
#9
02/27/2004 (4:05 pm)
Nate: I don't think you would get enough power to do it flawlessly anyway. Not with lightmaps, that's for sure.
#10
Fading between lightmaps is looking good too, but (don't know if i got it right) when you add a new interior you need to relight the whole scene several times, while with stencil shadows you only need to calc data for the building you're adding. Is this correct?
02/28/2004 (3:13 am)
It looks like stencil shadows are maybe the most professional solution, although i read that someone is working on adding them to torque and is getting a high fps drop. But i think it's ok, if it looks nice (and it does from screenshots i have seen).Fading between lightmaps is looking good too, but (don't know if i got it right) when you add a new interior you need to relight the whole scene several times, while with stencil shadows you only need to calc data for the building you're adding. Is this correct?
#11
02/28/2004 (3:30 am)
The lightmaps would need to be relighted, when you add a new interior. However, the stencil shadows need to be recalculated whenever the light positions change. In that case you need to determine the new silhouette from the light's point of view. However, some of that could be precomputed, too, and could be done only if the light's position changed considerably.
#12
02/28/2004 (4:16 am)
Well lights position would be constantly changing, cos there will be the sun moving across the sky for the day/night cycles.
#13
I once read a Game Developer magazine article on a Westwood implementation. If I am remembering correctly they used streaming compressed video for the terrain lightmap and another for the skydome using the DirectShow API. So the cloud shadows would match the skydome clouds. Seemed pretty efficient with low cpu processing cost since everything is precompiled. They used Terragen as the renderer. Basically a single frame from a video sequence was applied as a single lightmap texture pass to the terrain. Same for the sky dome.
There was also a description of the realtime method used for Earth & Beyond MMORPG.
I believe the article was called 'Photorealistic Terrain Lighting In Real Time'.
I would link to the article, but Gamasutra.com's search function seems to be down.
02/28/2004 (4:17 am)
On terrain lightmaps.I once read a Game Developer magazine article on a Westwood implementation. If I am remembering correctly they used streaming compressed video for the terrain lightmap and another for the skydome using the DirectShow API. So the cloud shadows would match the skydome clouds. Seemed pretty efficient with low cpu processing cost since everything is precompiled. They used Terragen as the renderer. Basically a single frame from a video sequence was applied as a single lightmap texture pass to the terrain. Same for the sky dome.
There was also a description of the realtime method used for Earth & Beyond MMORPG.
I believe the article was called 'Photorealistic Terrain Lighting In Real Time'.
I would link to the article, but Gamasutra.com's search function seems to be down.
#14
02/28/2004 (9:34 am)
That's a neat idea. If you do find a link, I'd be interested in looking at it. Or I guess I could get off my butt and try to find it myself... :P 
#15
Craig, if its an MMORPG will it be turn based? Just curious because if its not the players turn or if they are focused on somthing else you could relight the scene. In most intsances it will take less than a couple of seconds and if the day passes slowly you wont have to do it that often. If the day takes 2 hours of actual playing time you could relight the scene once every 10 - 15 minutes.
02/28/2004 (3:47 pm)
Joe, that sounds cool. Craig, if its an MMORPG will it be turn based? Just curious because if its not the players turn or if they are focused on somthing else you could relight the scene. In most intsances it will take less than a couple of seconds and if the day passes slowly you wont have to do it that often. If the day takes 2 hours of actual playing time you could relight the scene once every 10 - 15 minutes.
#16
gdconf_hoffman_doc
gdconf_hoffman_ppt
02/29/2004 (4:11 am)
I actually found a Game Developers Conference .doc and .ppt presentation of the same article.gdconf_hoffman_doc
gdconf_hoffman_ppt
#17
So, I was thinking that you could possibly add the option to slow down the rate at which the lightmap was calculated, and just relight in the backgroud, running one iteration per second (or whatever) continuously. When it finishes relighting, just kick it off again. That means that some parts of the map will be lit with the sun in a slightly different position to other parts, and you might see shadows jump if you're watching something as its lightmap is recalculated. However, at the rate that the sun's position changes, both of these effects could potentially be very subtle.
The downside with this otherwise very simple change is that the engine appears to be coded to not render when in the middle of a re-light. I haven't looked into this any further, to see how hard it would be to make it do so, and whether (for example) it blanks the lightmap initially, rather than over-writing it in place. However, if it could be made to work, it would be quite a simple change that appears to achieve what I want.
02/01/2005 (5:40 pm)
I've been thinking about this too. If you have a look at the SceneLighting::light function that is called when you re-light the scene, you can see that it actually doesn't run all at once... it's called multiple times with Sim::postEvent (the C++ version of the torquescript "schedule" function) at the end to schedule the next iteration one time-step in the future.So, I was thinking that you could possibly add the option to slow down the rate at which the lightmap was calculated, and just relight in the backgroud, running one iteration per second (or whatever) continuously. When it finishes relighting, just kick it off again. That means that some parts of the map will be lit with the sun in a slightly different position to other parts, and you might see shadows jump if you're watching something as its lightmap is recalculated. However, at the rate that the sun's position changes, both of these effects could potentially be very subtle.
The downside with this otherwise very simple change is that the engine appears to be coded to not render when in the middle of a re-light. I haven't looked into this any further, to see how hard it would be to make it do so, and whether (for example) it blanks the lightmap initially, rather than over-writing it in place. However, if it could be made to work, it would be quite a simple change that appears to achieve what I want.
#18
A lot of modern games using this kind of thing the burned in shadows almost never move, or exist at all for that matter, or are usually coming from 70-85 degrees top down so there are now long shadows, but because of the ambient light changes you almost never pick up on the fact that the "middle-ground" shadows coming from top down never realy move.
Smoke & Mirros might be easier then to implement a whole new system, but what you originally wanted would probably always look much better. :-)
I thought about this once, but have no idea how technically feasible it would be not having a programming background, but the light data is stored in a .ML file, it would be interesting to have 5-10 various ml files lit from various sun positions during the day and find some way to fade between them over time instead of having to actually relight the scene for every degree change in the sun. No idea how possible that would be though.
02/09/2005 (2:03 pm)
Another way is to not do this at all as it's pretty extensive, and I'm not sayig you should listen to this method, but if you look at a lot of games that use day/night cycles they and try to look at shadows, they cleverly get around this using ambient lighting, dark deep blue ambient lighting for night, orange and pink for afternoon and dawn, yellow/white for full-day. A lot of modern games using this kind of thing the burned in shadows almost never move, or exist at all for that matter, or are usually coming from 70-85 degrees top down so there are now long shadows, but because of the ambient light changes you almost never pick up on the fact that the "middle-ground" shadows coming from top down never realy move.
Smoke & Mirros might be easier then to implement a whole new system, but what you originally wanted would probably always look much better. :-)
I thought about this once, but have no idea how technically feasible it would be not having a programming background, but the light data is stored in a .ML file, it would be interesting to have 5-10 various ml files lit from various sun positions during the day and find some way to fade between them over time instead of having to actually relight the scene for every degree change in the sun. No idea how possible that would be though.
#19
I'm no longer working on this project, although the project is still going. One of the main reasons the moving shadows is so important was that the game had a very good system for skies and day/night. (Some quests actually used the angle of the sun etc... Also we had fractal clouds, and skies that would change colour during the day etc)
I'll find out if this was actually ever addressed, although I believe the project is moving over to TSE once the current milestone is complete also.
02/09/2005 (2:16 pm)
Way to dredge up an old thread. :DI'm no longer working on this project, although the project is still going. One of the main reasons the moving shadows is so important was that the game had a very good system for skies and day/night. (Some quests actually used the angle of the sun etc... Also we had fractal clouds, and skies that would change colour during the day etc)
I'll find out if this was actually ever addressed, although I believe the project is moving over to TSE once the current milestone is complete also.
#20
Thanks :) Ah, the hazards of being a newbie, following a link to the thread forwarded to me by a fellow TGE coder (so I didn't know how many screens back the thread was), and then not actually noticing the date before joining in the conversation...
Anyway, I actually gave my suggestion a try, removing the code that disabled rendering while re-lighting was happening. Unfortunately, even broken down into single iterations which ran only once a second, the lighting code caused noticeable hiccups in the engine.
@Tim, there's actually a post higher up in this very thread, by James Holmes, where he says he's done that. Has a link to screenshots and code and all. I haven't had a close look at it yet, but it may well be the way to go.
One disadvantage of the constant background re-lighting idea I suggested is that you'd either always have to re-light every time you connected to the server, or start running around with some sort of default lightmap that may differ radically from the current state while you wait for the first pass of the background re-light to finish. Pre-calculated lightmaps that you fade between wouldn't have such a problem - they'd be cached and could be re-used when re-connecting, just as the current single static one is.
02/09/2005 (8:03 pm)
Quote:Way to dredge up an old thread. :D
Thanks :) Ah, the hazards of being a newbie, following a link to the thread forwarded to me by a fellow TGE coder (so I didn't know how many screens back the thread was), and then not actually noticing the date before joining in the conversation...
Anyway, I actually gave my suggestion a try, removing the code that disabled rendering while re-lighting was happening. Unfortunately, even broken down into single iterations which ran only once a second, the lighting code caused noticeable hiccups in the engine.
@Tim, there's actually a post higher up in this very thread, by James Holmes, where he says he's done that. Has a link to screenshots and code and all. I haven't had a close look at it yet, but it may well be the way to go.
One disadvantage of the constant background re-lighting idea I suggested is that you'd either always have to re-light every time you connected to the server, or start running around with some sort of default lightmap that may differ radically from the current state while you wait for the first pass of the background re-light to finish. Pre-calculated lightmaps that you fade between wouldn't have such a problem - they'd be cached and could be re-used when re-connecting, just as the current single static one is.
Torque Owner Britton LaRoche