Strange green/purple lighting issues with difs
by Michael K. · in Torque Game Engine Advanced · 10/19/2008 (8:20 am) · 7 replies
Hi,
i am getting strange green and purple lights on my dif's when moving around. I checked all the lights and i can't find the problem. Sometimes my player also turns green or purple when running around the difs.
Here's a picture to explain the problem:
(it's not the best example, but you can see a green light)
It also seems to matter at what angle i look at the difs.
Any help would be great.
Thanks,
Michael
i am getting strange green and purple lights on my dif's when moving around. I checked all the lights and i can't find the problem. Sometimes my player also turns green or purple when running around the difs.
Here's a picture to explain the problem:
(it's not the best example, but you can see a green light)It also seems to matter at what angle i look at the difs.
Any help would be great.
Thanks,
Michael
#2
Hope this gets fixed in 1.8
10/19/2008 (10:55 am)
Yes, i'm using the current map2dif_plus_tgea exporter.... i'll check the bug forum, thank you!Hope this gets fixed in 1.8
#3
edit: Here's the original link mentioning it and a few other bugs: www.garagegames.com/mg/forums/result.thread.php?qt=76361
10/19/2008 (4:26 pm)
Me too, but the performance is outstanding with map2dif_plus_tgea.edit: Here's the original link mentioning it and a few other bugs: www.garagegames.com/mg/forums/result.thread.php?qt=76361
#4
I believe I've resolved the issue by reintroducing the SG_LIGHTMAP_BORDER_SIZE functionality into both lmapPacker.h & lmapPacker.cpp (using an old included map2dif from the 1.0.3 version).
What appears to have happened (and remember, I'm an artist, not a coder), is that when certain parts of the TLK/SG lighting code was being phased out(?) of TGEA, the ability to set the lightmap border size was removed/commented out, so no matter what border size you might call for in you .MAP file, it wouldn't resize and therefore if you resized your DIF in Engine, the lightmapping would get wonked, and your player would pass through the lightmap borders, i.e. green or purple.
Like I mentioned, I've reintroduced the code, and it *seems* to work fine, but there are two caveats;
1) I am using an older version of the SDK (since the last several have not included the Map2Dif source).
2) For the life of me I can't seem to get a release build to compile (linker error to engine.lib -- I'm sure that this is something that someone who actually knows what they are doing could resolve easily) and so I'm using a debug version of the map2dif_plus_tse.
If anyone is interested, I'm going to upload it to my host and post a link so that you can test it and see if in the process of fixing one thing I didn't break something else. Also it would be really helpful if the Map2Dif source was reintroduced into the SDK...
I'll crosspost this in one or two other threads where I've seen this issue discussed and not resolved.
Thanks,
Alan
Edit:
Here is the Modified map2dif_plus_tse, remember this is definitely an "as is" piece of coding, based upon an older SDK and your mileage may vary:
www.monsterpacks.com/contentpacks/code/map2dif_plus_tse.exe
*EDIT EDIT EDIT*
Ok, so this works, but it is definitely not right (but I believe heading in the right direction) Map2Dif crashes on complex .MAP exporting in exportGeometry.cpp and I think it has something to do with sgGetLightingScale. Out of 70+ models I test exported, about thirty crashed and they all were over 1500+ faces.
So at this point I've reached pretty much the limit of my capabilities, I've tried selecting out and merging what I thought would resolve this from the standard Map2Dif, but I end up with a half a dozen errors (at best) and I'm way above my head on trying to figure this out.
Hopefully this will point someone who knows what they are doing in the right direction.
02/23/2009 (11:39 am)
I don't know if anyone is still following this thread, but I'm pretty sure the problem was introduced prior to 1.0.3, and I'm also pretty sure I've got a working solution. I believe I've resolved the issue by reintroducing the SG_LIGHTMAP_BORDER_SIZE functionality into both lmapPacker.h & lmapPacker.cpp (using an old included map2dif from the 1.0.3 version).
What appears to have happened (and remember, I'm an artist, not a coder), is that when certain parts of the TLK/SG lighting code was being phased out(?) of TGEA, the ability to set the lightmap border size was removed/commented out, so no matter what border size you might call for in you .MAP file, it wouldn't resize and therefore if you resized your DIF in Engine, the lightmapping would get wonked, and your player would pass through the lightmap borders, i.e. green or purple.
Like I mentioned, I've reintroduced the code, and it *seems* to work fine, but there are two caveats;
1) I am using an older version of the SDK (since the last several have not included the Map2Dif source).
2) For the life of me I can't seem to get a release build to compile (linker error to engine.lib -- I'm sure that this is something that someone who actually knows what they are doing could resolve easily) and so I'm using a debug version of the map2dif_plus_tse.
If anyone is interested, I'm going to upload it to my host and post a link so that you can test it and see if in the process of fixing one thing I didn't break something else. Also it would be really helpful if the Map2Dif source was reintroduced into the SDK...
I'll crosspost this in one or two other threads where I've seen this issue discussed and not resolved.
Thanks,
Alan
Edit:
Here is the Modified map2dif_plus_tse, remember this is definitely an "as is" piece of coding, based upon an older SDK and your mileage may vary:
www.monsterpacks.com/contentpacks/code/map2dif_plus_tse.exe
*EDIT EDIT EDIT*
Ok, so this works, but it is definitely not right (but I believe heading in the right direction) Map2Dif crashes on complex .MAP exporting in exportGeometry.cpp and I think it has something to do with sgGetLightingScale. Out of 70+ models I test exported, about thirty crashed and they all were over 1500+ faces.
So at this point I've reached pretty much the limit of my capabilities, I've tried selecting out and merging what I thought would resolve this from the standard Map2Dif, but I end up with a half a dozen errors (at best) and I'm way above my head on trying to figure this out.
Hopefully this will point someone who knows what they are doing in the right direction.
#5
02/23/2009 (4:17 pm)
Well done Alan. Admittedly most of my DIFs are huge but a quick mock-up of some smaller ones and it certainly seems to work.
#6
www.monsterpacks.com/contentpacks/code/v2/map2dif_plus_tse.exe
02/24/2009 (12:48 pm)
OK, here is a super duper hack, all I changed with this one is the default colors of the lightmap borders (neutral grey). This one should work with pretty much any sized .MAP, obviously the issue still is that the lightmapping effects on the player will not be accurate, but at least it's very subtle depending upon the map itself - and they're not purple or green!:www.monsterpacks.com/contentpacks/code/v2/map2dif_plus_tse.exe
#7
That's fantastic! It took me a while to even spot the lightmap/player issue, it really is very subtle, and only really noticeable when moving back and forth between terrain and DIF surface. It's a lot easy to live with than green brush splits though!
My 6300+ surface/2250+ brush map exported. It looks great and the performance is still excellent.
For someone who claimed to be "an artist not a coder" I think that you've done magnificiently. Well done.
May I suggest that you write up a blog post about this, as more people are likely to read that and notice what you have achieved.
02/24/2009 (2:36 pm)
Tricorn hats off to you, sir.That's fantastic! It took me a while to even spot the lightmap/player issue, it really is very subtle, and only really noticeable when moving back and forth between terrain and DIF surface. It's a lot easy to live with than green brush splits though!
My 6300+ surface/2250+ brush map exported. It looks great and the performance is still excellent.
For someone who claimed to be "an artist not a coder" I think that you've done magnificiently. Well done.
May I suggest that you write up a blog post about this, as more people are likely to read that and notice what you have achieved.
Associate Steve Acaster
[YorkshireRifles.com]
It's been mentioned before in the bug forum.