Polished up daylight cycles
by Chris \"Hobbiticus\" Weiland · 03/31/2003 (11:10 am) · 71 comments
Download Code File
Basically, I've rewritten and torque-ized Josh Ritter's day/night cycles to be a lot more robust. Instead of keeping everything in ugly and "unstable" externs, I've put everything into it's own class with good stuff like information hiding. It's still a little ugly because of all of the statics, however.
All you should have to do is apply the patch to a head version of torque, add the game/fx/daylightCycle.h/cc to your project file, compile and run.
Also, IF YOU GET MY TERRAIN BUMP MAPPING CODE (now available), you can go change this:
Then you will get dynamically generated bumps that change with the sun vector!
Added benefits:
Ability to get sunlight vector/color easily, only runs when sky is being rendered, modular, scalable, toggleable.
Have fun!
Basically, I've rewritten and torque-ized Josh Ritter's day/night cycles to be a lot more robust. Instead of keeping everything in ugly and "unstable" externs, I've put everything into it's own class with good stuff like information hiding. It's still a little ugly because of all of the statics, however.
All you should have to do is apply the patch to a head version of torque, add the game/fx/daylightCycle.h/cc to your project file, compile and run.
Also, IF YOU GET MY TERRAIN BUMP MAPPING CODE (now available), you can go change this:
VectorF sunVector; //if you use my updated day/night cycles you can use this for dynamic bumps //sunVector = DaylightCycle::getTrueSunVector(); static Vector<LightInfo*> lights; lights.clear(); gClientSceneGraph->getLightManager()->getLights(lights); sunVector = -lights[0]->mDirection; //first light is always sun //find s and t tangentsto this:
VectorF sunVector = DaylightCycle::getTrueSunVector(); //find s and t tangentsin terrRender.cc
Then you will get dynamically generated bumps that change with the sun vector!
Added benefits:
Ability to get sunlight vector/color easily, only runs when sky is being rendered, modular, scalable, toggleable.
Have fun!
#2
04/01/2003 (3:05 am)
OMG i stopped using TGEDN due to crashes, thanks alot! Im glad your maintaining it.
#3
EDIT: It looks like to do what I want to do will require putting more of the calculations onto the GPU, which may actually SPEED UP the rendering process. Of course, it may slow it down on lower end graphics cards, but the higher end (3+ TMU) should definately get a boost!
EDIT: Never mind, found another way to do it that requires a lot less work, but now instead of just high end cards getting a boost, all cards should! Basically it'll return the performance to what it is without the cycling in place. Again, the difference will probably be unnoticable.
04/01/2003 (9:08 am)
My team just found that the interior render is still not quite exact, but nothing major - I'm researching how to fix it. I know what I have to do, but I don't know how to go about doing it. I'll try to update the resource ASAP. I'll post a patch to upgrade from scratch and a little blurb about how to fix it if you already got the existing one. You probably won't tell the difference.EDIT: It looks like to do what I want to do will require putting more of the calculations onto the GPU, which may actually SPEED UP the rendering process. Of course, it may slow it down on lower end graphics cards, but the higher end (3+ TMU) should definately get a boost!
EDIT: Never mind, found another way to do it that requires a lot less work, but now instead of just high end cards getting a boost, all cards should! Basically it'll return the performance to what it is without the cycling in place. Again, the difference will probably be unnoticable.
#4
I'd appreciate a bit of help if anyone has the time:
I'm looking to add this to my game so that it gets brighter when the good guys are winning and darker when the bad guys are winning. I have a global score int in script that varies from -8 to 8 depending on who is winning. If I set the brightness level in 1 sudden step, it will jump and look odd. So for example if the score changes from 0 to 1 I want it to get a bit brighter continuously over, say, a 10 second period. Maybe I should have a 'targetBrightness' value, or something similar?
The patch in this zip is quite confusing to follow as it seems to make alterations in many files and I'm having a hard time finding out what I should be modifying.
I'm fairly new to Torque and most of my work so far has been in script. I'm guessing that I'll need to access my global script score variable from C++, so how to I go about this? Can I do something with findObject()? Or do I need to add it to the PersistFields ?
Any hints on how to go about what I'm planning would be really great.
Thanks.
04/09/2003 (8:23 am)
Hi, this is great - thanks. I'd appreciate a bit of help if anyone has the time:
I'm looking to add this to my game so that it gets brighter when the good guys are winning and darker when the bad guys are winning. I have a global score int in script that varies from -8 to 8 depending on who is winning. If I set the brightness level in 1 sudden step, it will jump and look odd. So for example if the score changes from 0 to 1 I want it to get a bit brighter continuously over, say, a 10 second period. Maybe I should have a 'targetBrightness' value, or something similar?
The patch in this zip is quite confusing to follow as it seems to make alterations in many files and I'm having a hard time finding out what I should be modifying.
I'm fairly new to Torque and most of my work so far has been in script. I'm guessing that I'll need to access my global script score variable from C++, so how to I go about this? Can I do something with findObject()? Or do I need to add it to the PersistFields ?
Any hints on how to go about what I'm planning would be really great.
Thanks.
#5
04/10/2003 (7:35 am)
Is this a patch against the existing DN code, or from the HEAD?
#6
Alastair, most of the time, you don't want your C++ code touching script variables in cases such as yours. You script is what's controling score, and your brightness is based on score, so keep all the functionality in one place. You'd have to do a lot of tinkering with daylightCycle.cc, specifically with color targets.
Then, you need to make a ConsoleFunction that your script will hook into that tells the cycling which color target to aim at next, etc. To do what you're trying to do, it's definately going to be some work, but the basic functionality is already there.
The only files you should have to change are daylightCycle.cc/h. Everything else just hooks into those to get the right color to use for lighting, etc.
04/10/2003 (4:42 pm)
it's against headAlastair, most of the time, you don't want your C++ code touching script variables in cases such as yours. You script is what's controling score, and your brightness is based on score, so keep all the functionality in one place. You'd have to do a lot of tinkering with daylightCycle.cc, specifically with color targets.
Then, you need to make a ConsoleFunction that your script will hook into that tells the cycling which color target to aim at next, etc. To do what you're trying to do, it's definately going to be some work, but the basic functionality is already there.
The only files you should have to change are daylightCycle.cc/h. Everything else just hooks into those to get the right color to use for lighting, etc.
#7
04/12/2003 (12:52 pm)
anyone know how to unapply the original patch? 
#8
04/12/2003 (6:31 pm)
anyone know how to apply the patch? I have no clue how to do this
#9
Sorry I can explain patching :) I can just do.
04/13/2003 (2:05 pm)
I can aplly patches, I am wandering is this something I can patch over the old tgend code or do I have to remove it first.Sorry I can explain patching :) I can just do.
#10
It is indeed much cleaner than the original code.
I particularly appreciate the toggleability (or whatever it is called ;) )
Thanks!
Isi
04/23/2003 (1:21 am)
Very nice resource!It is indeed much cleaner than the original code.
I particularly appreciate the toggleability (or whatever it is called ;) )
Thanks!
Isi
#11
in daylightCycle.cc, line 154 (ish)
shouldn't the line:
rather be:
?
I was having strange effects while using the "Fractal sky" resource, and this seemed to be one of the reasons.
Isi
04/24/2003 (4:20 pm)
By the way, I think there is something wrong.in daylightCycle.cc, line 154 (ish)
shouldn't the line:
mFogColor = mCurrentBandColor;
rather be:
mFogColor = mCurrentBandColor * mOrigionalFogColor;
?
I was having strange effects while using the "Fractal sky" resource, and this seemed to be one of the reasons.
Isi
#12
I've noticed that shadows, at least the player's shadow, do not change position as the day cycle changes. Any chance somethign was left out of the patch or is this just another TerrainManager wierdism I need to track down?
I'm looking at things now and I'll let you know if I find anything.
04/26/2003 (5:23 am)
Chris,I've noticed that shadows, at least the player's shadow, do not change position as the day cycle changes. Any chance somethign was left out of the patch or is this just another TerrainManager wierdism I need to track down?
I'm looking at things now and I'll let you know if I find anything.
#13
In player.cc make sure the light vector the shadow gets its light source from is being set via something like so:
That should update the players shadow. If it doesn't, it could be a TerrainManager issue then :/
05/01/2003 (4:05 am)
Stanley,In player.cc make sure the light vector the shadow gets its light source from is being set via something like so:
VectorF sunVector = DaylightCycle::getTrueSunVector();
That should update the players shadow. If it doesn't, it could be a TerrainManager issue then :/
#14
Adrian: You're probably going to have to use "winmerge" (google for it) to unapply Josh Ritter's code. You have to open up your "infected" file and the origional file and go through each discrepency and sort it out for each file that it altered.
Travis: See the CVS documentation on this site and look at the very bottom - it'll tell you how to apply patches.
Isidore: if it helps, change it, but it's not supposed to be like that, afaik. It could be a discrepency between the fractal sky and the default torque sky.
Donovan: You or I probably missed what Robert said. Although, it should be sunVector = DaylightCycle::getSunVector(); getTrueSunVector() will have some issues with it as it's basically a hack for the terrain lighting.
05/05/2003 (2:50 pm)
Oh cool, the comments didn't go dead...heh.Adrian: You're probably going to have to use "winmerge" (google for it) to unapply Josh Ritter's code. You have to open up your "infected" file and the origional file and go through each discrepency and sort it out for each file that it altered.
Travis: See the CVS documentation on this site and look at the very bottom - it'll tell you how to apply patches.
Isidore: if it helps, change it, but it's not supposed to be like that, afaik. It could be a discrepency between the fractal sky and the default torque sky.
Donovan: You or I probably missed what Robert said. Although, it should be sunVector = DaylightCycle::getSunVector(); getTrueSunVector() will have some issues with it as it's basically a hack for the terrain lighting.
#15
1: If a client connects to a server whose "timescale" differs from default (even if it is set correctly in the client's mis file), the cycle on the client will have the default timescale.
- This can be temporarily "solved" by changing default values in sky.cc and daylight.cc of course, but i'm sure there must be some better way.
2: Fog effects look odd
- I solved this by changing this line in sky.cc:
if((alphaBan[1] < 1.0f || mNumFogVolumes == 0) && (!FractalSky))
to:
if((alphaBan[1] < 1.0f || mNumFogVolumes == 0))
Then I created a skybox file like this:
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
cloud1
cloud1
where sky_flat.jpg is some flat blue jpg in the same dir as the skybox file.
Then i used this skybox in my .mis file, making sure that:
useSkyTextures = "1"
@Isidore: i wouldn't change that, it may be an interesting effect, but not a very realistic one ;)
3: When you join a server, the terrain is lit as if it was noon, even during the night. Starting a mission works correctly, tho.
EDIT: I found a way to partially fix this, see my post below.
To be honest, i don't think that problem number 3 depends on the fractal sky resource, but i haven't had time to test it. Is anyone else experiencing this problem?
05/06/2003 (9:25 am)
This is an awesome resource, but I'm having some problems running it together with Fractal Sky.1: If a client connects to a server whose "timescale" differs from default (even if it is set correctly in the client's mis file), the cycle on the client will have the default timescale.
- This can be temporarily "solved" by changing default values in sky.cc and daylight.cc of course, but i'm sure there must be some better way.
2: Fog effects look odd
- I solved this by changing this line in sky.cc:
if((alphaBan[1] < 1.0f || mNumFogVolumes == 0) && (!FractalSky))
to:
if((alphaBan[1] < 1.0f || mNumFogVolumes == 0))
Then I created a skybox file like this:
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
sky_flat
cloud1
cloud1
where sky_flat.jpg is some flat blue jpg in the same dir as the skybox file.
Then i used this skybox in my .mis file, making sure that:
useSkyTextures = "1"
@Isidore: i wouldn't change that, it may be an interesting effect, but not a very realistic one ;)
3: When you join a server, the terrain is lit as if it was noon, even during the night. Starting a mission works correctly, tho.
EDIT: I found a way to partially fix this, see my post below.
To be honest, i don't think that problem number 3 depends on the fractal sky resource, but i haven't had time to test it. Is anyone else experiencing this problem?
#16
In fact, the reason why I made this change is because it looks that it was the way it was done in TGEDayNight (i end up with the same visual result with both TGEDayNight and this resource when making this change)
Besides, I thought there was a problem as the fog color (when daynight is active) didn't depend at all on the mission fog color (ie: as far as I saw, mFogColor depends only on mCurrentBandColor, which it self has no link to the mission fog). And I ended up with a bright sky.
Anyway, I will try your changes to see the difference.
Cheers,
Isi
05/09/2003 (12:18 am)
@Hadoken In fact, the reason why I made this change is because it looks that it was the way it was done in TGEDayNight (i end up with the same visual result with both TGEDayNight and this resource when making this change)
Besides, I thought there was a problem as the fog color (when daynight is active) didn't depend at all on the mission fog color (ie: as far as I saw, mFogColor depends only on mCurrentBandColor, which it self has no link to the mission fog). And I ended up with a bright sky.
Anyway, I will try your changes to see the difference.
Cheers,
Isi
#18
I believe that this resource sets the fog color for the scene without caring about your mission color. But it does care about the skybox, blending it with the fog color instead of replacing it. The problem is that fractal sky skips the renering of the skybox because it wants to fill the space above the fractal clouds with the fog color. I think that forcing a flat blue skybox to be rendered behind the clouds could make both this resource and fractal sky look right.
05/11/2003 (10:27 am)
@IsidoreI believe that this resource sets the fog color for the scene without caring about your mission color. But it does care about the skybox, blending it with the fog color instead of replacing it. The problem is that fractal sky skips the renering of the skybox because it wants to fill the space above the fractal clouds with the fog color. I think that forcing a flat blue skybox to be rendered behind the clouds could make both this resource and fractal sky look right.
#19
I've been playing around with daylight cycles and have managed to implement what I was trying to do in my pos t as of April 9th.
I have a global script variable defined on the server and passed to clients via a commandToClient function whenever it changes.
This script variable is read by daylightcycle.cc code and it calculates the time of day based on this.
OK, so it all works fine... in single player mode.
When the time of day gets late, then, yes, things get darker as they are supposed to. The sky, the terrain, the shapes, the player models... all fine.
HOWEVER, this only works if the client and server are on the same machine. Ie, single player, or multi-player using a listen server not a dedicated one.
In dedicated server mode, (or listen server mode to all clients except the one running the server), then all clients have the following problem: That the terrain and waterblocks do not get darker. The rest of the stuff - Shapes, sky, models, sun etc. - all work correctly, just not the terrain and water.
Something was mentioned about recalculating the lightmaps on the server, but it is an expensive operation. However as this change of time/light level is relatively infrequent, it maybe ok to do this.
Anyway, if anyone knows why the terrain does not get darker and how to fix this, I'd appreciate it.
Cheers,
Ali
05/12/2003 (8:45 am)
Hmm, looks as if my last post didn't appear. Repeated here. Apologies if it appears twice...I've been playing around with daylight cycles and have managed to implement what I was trying to do in my pos t as of April 9th.
I have a global script variable defined on the server and passed to clients via a commandToClient function whenever it changes.
This script variable is read by daylightcycle.cc code and it calculates the time of day based on this.
OK, so it all works fine... in single player mode.
When the time of day gets late, then, yes, things get darker as they are supposed to. The sky, the terrain, the shapes, the player models... all fine.
HOWEVER, this only works if the client and server are on the same machine. Ie, single player, or multi-player using a listen server not a dedicated one.
In dedicated server mode, (or listen server mode to all clients except the one running the server), then all clients have the following problem: That the terrain and waterblocks do not get darker. The rest of the stuff - Shapes, sky, models, sun etc. - all work correctly, just not the terrain and water.
Something was mentioned about recalculating the lightmaps on the server, but it is an expensive operation. However as this change of time/light level is relatively infrequent, it maybe ok to do this.
Anyway, if anyone knows why the terrain does not get darker and how to fix this, I'd appreciate it.
Cheers,
Ali
#20
1: Good call. I don't think I ever sent the timescale to the clients. I'll get on that.
2: That sort of thing will happen when you have a really dark sky. It's kinda on my todo list to scale the colors so that it won't go completely bright when the sky is dark. I DOUBT I'll get around to this any time soon. But, if you really need it dark, you can scale down the hardcoded values for the color targets.
3: The terrain is lit how it would be without the cycling on. This is because the terrain is lit using light maps that are computed at load time because it takes a few seconds to do. It's just an artifact you'll have to live with.
Alastar:
You're probably missing the recalculation somehow. To get the color to modulate everything by, it just grabs a variable. That variable SHOULD be precomputed - you probably just have to move the call to the recalc function of the cycles.
Oh, forgot to note: The bumpmapping resource has been posted, and it available for download. I would post a link, but I'm too lazy and if I goto a different page, my entire post will be gone. But it's there, trust me :)
05/12/2003 (12:10 pm)
@Hadoken:1: Good call. I don't think I ever sent the timescale to the clients. I'll get on that.
2: That sort of thing will happen when you have a really dark sky. It's kinda on my todo list to scale the colors so that it won't go completely bright when the sky is dark. I DOUBT I'll get around to this any time soon. But, if you really need it dark, you can scale down the hardcoded values for the color targets.
3: The terrain is lit how it would be without the cycling on. This is because the terrain is lit using light maps that are computed at load time because it takes a few seconds to do. It's just an artifact you'll have to live with.
Alastar:
You're probably missing the recalculation somehow. To get the color to modulate everything by, it just grabs a variable. That variable SHOULD be precomputed - you probably just have to move the call to the recalc function of the cycles.
Oh, forgot to note: The bumpmapping resource has been posted, and it available for download. I would post a link, but I'm too lazy and if I goto a different page, my entire post will be gone. But it's there, trust me :)
Torque Owner Nicolas Quijano
Thx Chris, smells darn good from here... 8p