Screwed lightmaps when Alt-Tabing and Caching is off.
by Stefan Lundmark · in Torque Game Engine · 11/14/2004 (8:05 am) · 34 replies
This problem applies to 1.2.2 (haven't tried it on 1.3 yet but there are no changes made that suggest that this have been fixed).
If you alt-tab out of your game, and go back in.. the game won't render any lightmaps at all. Putting a relight command in the code when you maximize the game again, solves the problem. The console also reports an error that lightmaps cannot be loaded.
This does only happen when you have caching set to off, as far as our testing has shown, anyway.
If you alt-tab out of your game, and go back in.. the game won't render any lightmaps at all. Putting a relight command in the code when you maximize the game again, solves the problem. The console also reports an error that lightmaps cannot be loaded.
This does only happen when you have caching set to off, as far as our testing has shown, anyway.
About the author
#22
This could be the problem:
"cachelightning = 0"
It should be:
$pref::sceneLighting::cacheLighting = 0;
08/10/2005 (9:27 am)
Billy,This could be the problem:
"cachelightning = 0"
It should be:
$pref::sceneLighting::cacheLighting = 0;
#23
08/10/2005 (9:41 am)
I think that's just a typo in the post but, worth a try.
#24
Clints fix didnt help , why this was working on my version was because i used vertexlighting on.
@Stefan why do you want to use a non ml file ?
If you want to speed the loading process then writeprotect the ml file.
08/10/2005 (9:43 am)
Ye John typo fault by me :)Clints fix didnt help , why this was working on my version was because i used vertexlighting on.
@Stefan why do you want to use a non ml file ?
If you want to speed the loading process then writeprotect the ml file.
#25
The problem occurs because alt-tabbing in full screen mode trashes the textures load into the render context, disabling "cacheLighting" tells TGE not to save out the scene lighting data, and TGE deletes the system memory copy of scene lighting data to conserve memory. Under these conditions the GL scene lighting textures are gone, TGE doesn't have a system memory copy, and TGE was told not to save a persistent copy. Other than doing a full relight, the solution is to only disable "cacheLighting" in windowed mode.
08/10/2005 (9:47 am)
I can reproduce this consistently using stock TGE 1.3, however I don't think this is really a bug, it's more a function of how "cacheLighting" works.The problem occurs because alt-tabbing in full screen mode trashes the textures load into the render context, disabling "cacheLighting" tells TGE not to save out the scene lighting data, and TGE deletes the system memory copy of scene lighting data to conserve memory. Under these conditions the GL scene lighting textures are gone, TGE doesn't have a system memory copy, and TGE was told not to save a persistent copy. Other than doing a full relight, the solution is to only disable "cacheLighting" in windowed mode.
#26
I do however think that it's important that it does work.. the cache files can get many and large pretty soon. That's originally (and for testing purposes) why I did set it that way too.
There's really no use to have caching set to 0, when this issue exists.
08/10/2005 (10:09 am)
Yeah, that's what I thought too. Not really a bug but rather a sideeffect of how caching works.I do however think that it's important that it does work.. the cache files can get many and large pretty soon. That's originally (and for testing purposes) why I did set it that way too.
There's really no use to have caching set to 0, when this issue exists.
#27
I didn't realize that's what you were using it for, instead try setting "$pref::sceneLighting::cacheSize" to a smaller size (in bytes). This setting forces TGE to prune old ml files to maintain the cache size - I use this a lot, it's a very cool feature. :)
08/10/2005 (10:14 am)
"the cache files can get many and large pretty soon"I didn't realize that's what you were using it for, instead try setting "$pref::sceneLighting::cacheSize" to a smaller size (in bytes). This setting forces TGE to prune old ml files to maintain the cache size - I use this a lot, it's a very cool feature. :)
#28
If the ml file is write protected Torque dont do a new light process, it uses the information from the ml file.
08/10/2005 (10:15 am)
Ye but if he use a writeprotected .ml file then he can have cacheLighting off if he wants to and still use Alt Tab .If the ml file is write protected Torque dont do a new light process, it uses the information from the ml file.
#29
08/10/2005 (10:17 am)
But then, TGE is using outdated lighting information and you'll still need to perform a relight to get the lighting used prior to the alt-tab.
#30
I mean when you finished the map then you write protect the ml file and i dont see any reason for to relight the scene another time.
I have done this long time ,my finished maps looks the same as they did when i made them and it works real good.
What do you mean should happen John ,because i cant see any differens when i Alt Tab ?
08/10/2005 (10:32 am)
Hmm Outdated ?I mean when you finished the map then you write protect the ml file and i dont see any reason for to relight the scene another time.
I have done this long time ,my finished maps looks the same as they did when i made them and it works real good.
What do you mean should happen John ,because i cant see any differens when i Alt Tab ?
#31
But if you're not making changes to the mission, why disable caching? In my mind disabling caching only performs two functions; conserving disk space (which the cache size is better suited for) and forcing a relight every time the mission is loaded. Keeping a read-only version of the ml file prevents the forced relight, so why is caching disabled? It can't be to avoid a relight when restarting the mission because the relight is based on the mission file CRC check - either the mission didn't change (so there wouldn't have been a relight anyway), or the mission changed and the ml file isn't found (because the filename is based on the CRC value) so a relight will still happen.
I guess I don't understand what you're trying to do.
08/10/2005 (11:01 am)
If you are not changing the mission you shouldn't notice a difference - I'm saying that if you change the mission like moving renderable objects around, you're likely to make a change that requires a relight, if that happens and you alt-tab the lighting will revert to the lighting from before the change (the outdated version).But if you're not making changes to the mission, why disable caching? In my mind disabling caching only performs two functions; conserving disk space (which the cache size is better suited for) and forcing a relight every time the mission is loaded. Keeping a read-only version of the ml file prevents the forced relight, so why is caching disabled? It can't be to avoid a relight when restarting the mission because the relight is based on the mission file CRC check - either the mission didn't change (so there wouldn't have been a relight anyway), or the mission changed and the ml file isn't found (because the filename is based on the CRC value) so a relight will still happen.
I guess I don't understand what you're trying to do.
#33
I dont trying todo anything except discuss this topic .
08/10/2005 (11:37 am)
I understand you perfectly John :)I dont trying todo anything except discuss this topic .
#34
That's why I'm asking what you're trying to do, in case there's an easier way to do it.
Stefan,
No problem - it took me a long time to find that feature too. In fact I only found it because I was working on a large mission and the ml files kept vanishing. :) After a little debugging I found the cache size and it's been very handy ever since.
08/10/2005 (12:06 pm)
Me too. :)That's why I'm asking what you're trying to do, in case there's an easier way to do it.
Stefan,
No problem - it took me a long time to find that feature too. In fact I only found it because I was working on a large mission and the ml files kept vanishing. :) After a little debugging I found the cache size and it's been very handy ever since.
Torque Owner Stefan Lundmark