Dynamic Terrain Shadows: A Solution?
by Steven Peterson · in Torque Game Engine · 11/09/2005 (11:10 pm) · 4 replies
This may be the wrong forum - but close enough...
I've been thinking about trying to animate torque's "baked in" lighting shadows, and have an idea..
The problem is i'm using Celestial day/night and since the terrain shadows can't move I have the static-sun position at high-noon. This keeps the shadows from ever bening blatently wrong. However it also gives the game an "overcast and dreary" feel.
Possible Solution: Would it be possible to pre-calculate the "mission-terrain lighting" from all 360 degrees of sun-position around the 'earth'? Then write some script that changes the lightmap at regular intervals using some pre-existing time-system?
This shouldn't be too bad a performance hit because all the hard work (lighting calculations) are being done at start-up time and really it should only have to be done once. During in-game run-time the CPU hit should be negligable. If there are enough light-maps, then the change will be subtle and it shouldn't "jump" too much. If a fade effect could be added in, it would soften it even more.
From my understanding, you could even package the file(s) including the lightmaps (*.ter?) into your final product like anyother pre-compiled file. The user would never know the difference.
Is this feasable?
Does anyone know where to begin looking?
I've been thinking about trying to animate torque's "baked in" lighting shadows, and have an idea..
The problem is i'm using Celestial day/night and since the terrain shadows can't move I have the static-sun position at high-noon. This keeps the shadows from ever bening blatently wrong. However it also gives the game an "overcast and dreary" feel.
Possible Solution: Would it be possible to pre-calculate the "mission-terrain lighting" from all 360 degrees of sun-position around the 'earth'? Then write some script that changes the lightmap at regular intervals using some pre-existing time-system?
This shouldn't be too bad a performance hit because all the hard work (lighting calculations) are being done at start-up time and really it should only have to be done once. During in-game run-time the CPU hit should be negligable. If there are enough light-maps, then the change will be subtle and it shouldn't "jump" too much. If a fade effect could be added in, it would soften it even more.
From my understanding, you could even package the file(s) including the lightmaps (*.ter?) into your final product like anyother pre-compiled file. The user would never know the difference.
Is this feasable?
Does anyone know where to begin looking?
#2
I wonder how much extra work it would be to simply recalculate shadows as a back ground process, when an update is recieved from celestials. This would seem to me to solve the whole problem, but alas would require a new mission lighting file to be created and reloaded every so often.
11/10/2005 (12:54 am)
One solution I've found for situations where I want dynamic shadows is to use exclusively .dts shapes instead of .dif however this does not work for interior objects.I wonder how much extra work it would be to simply recalculate shadows as a back ground process, when an update is recieved from celestials. This would seem to me to solve the whole problem, but alas would require a new mission lighting file to be created and reloaded every so often.
#3
11/10/2005 (2:49 am)
www.garagegames.com/mg/forums/result.thread.php?qt=5403 Links have gone dead, but perhaps the author can still be reached.
#4
@Ben, thanks for the detailed response! :-)
My first question is where are you getting your "3mb" number from. My .ter file is about 1/2mb and my .ml files are coming in around 200k right now. Stronghold looks about < 1mb for a .ml. This is considerbly more doable.
Luckily my game is Action/RPG style and has only 1 level. Should I ever complete the extra quests, it will be 3 at most. Also if one got creative you could use less maps during the mid-day hours and more at sunrise/sunset and none at night to cut down on the sheer-volume.
A little bit of finess, a little bit of testing; I'm not ready to discard this idea without seeing it. In the other thread, James Holmes says he had about a 500ms lag when it changed maps, on on Pentium-1.5. With today's hardware that number should be a fraction of that.
11/10/2005 (2:13 pm)
@Erik, thanks for the post, I did indeed email the one author. WHen I have time i'm going to see if I can compare josh ritter's code to my resource, it sounds like he had some extra effects working that I don't.@Ben, thanks for the detailed response! :-)
My first question is where are you getting your "3mb" number from. My .ter file is about 1/2mb and my .ml files are coming in around 200k right now. Stronghold looks about < 1mb for a .ml. This is considerbly more doable.
Luckily my game is Action/RPG style and has only 1 level. Should I ever complete the extra quests, it will be 3 at most. Also if one got creative you could use less maps during the mid-day hours and more at sunrise/sunset and none at night to cut down on the sheer-volume.
A little bit of finess, a little bit of testing; I'm not ready to discard this idea without seeing it. In the other thread, James Holmes says he had about a 500ms lag when it changed maps, on on Pentium-1.5. With today's hardware that number should be a fraction of that.
Associate Kyle Carter
Cut down to half (sun can't shine through the earth :), and you're at half a gig. If you go to samples every ten degrees, you'll only be burning 54mb for your lighting info for a small mission. Of course, you have to upload all that lightmap info to the card every time you load new info, which will probably result in a significant hitch and a lot of disk I/O (streaming 3 megs of data in little chunks, decompressing it, and copying it around isn't fast).
And with sparse samples like that, you will probably have to fade to avoid lots of popping, which means you just doubled your lightmap memory usage, as well as eating a ton of fill rate, and having to touch a lot of rendering code. AND it won't look good in all cases (note how much the shadows change in a sunrise/sunset situation).
If your game has ten levels you'll be shipping almost half a gig of level data, or seeing a 20x increase in load times for first load situations.
So basically - nothing that's cheap and fast. You can do some exotic stuff with pixel shaders but that obviously won't work with TGE. :)