Torque bug? Would like feedback...

#1 What may be happening is that AA is sampling outside the visible range for the lightmap and getting garbage pixels.

#2 Hey Ben, good call I didn't realize that the light map borders were pink, but I dumped them out and sure enough the borders are pink.

I'll try to come up with a low risk solution for this. I certainly don't want to muck with the texture coords, otherwise shadows that span multiple surfaces won't line up properly. I'll try to at least make the artifacts look less noticeable.

-John

#3 Probably need to do a "border growing" pass so that every pixel adjacent to a pink pixel makes the pink pixel turn its color so that this AA problem won't happen...

#4 Ya, that's what I thought. Unfortunately a lot of the light maps are right next to each other causing bleeding, which means I'll need to change the light map packer to fix those too. Still exploring...

#5 I'll be interested in seeing what you come up with!

#6 Ok, I finally had a chance to work on this issue last night and got the borders working without much fuss, however I need some community feedback regarding this solution and where to take it next.


Here's the issue:

Although I've solved the green/pink line anti-aliasing problem, less obvious visual artifacts can still occur due to mission lighting not taking the border into account, however if the border is added to mission lighting difs compiled with older map2difs would crash Torque with access overruns or at the very least make one hell of a mess of the light maps.


Here's the question:

Would we rather solve this 100% and make life rather annoying or half ass it to keep life simple? Or does anyone have a better idea for handling the borders in mission lighting?


Personally I don't want to recompile my difs, besides I can't tell you how many times I've screwed up map2dif 'experimenting' and used an old version that was floating around to prove that the map file wasn't the issue (of course I could just stop changing code and content at the same time, but that wouldn't be nearly as much fun :). On the other hand visual artifacts offend me to no end.


Btw: I've yet to see if the scene lighting code can be updated without a huge mess, those of you who've seen or worked with scene lighting know what I'm talking about... oh my.

Comments appreciated!

-John

#7 @John,

There is a Scene Lighting patch that was never committed to the cvs, which provides a slightly more generic interface for the proxy lighting...
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=4947
However, it did have a few problems when you didn't have any interiors in your mission, as i have described in the comments.

#8 Hi James,

Thanks for the patch, but my reference was to scene lighting's actual lighting code, which it looks like the patch still contains.

Thinking back on it the really touchy code was in terrainproxy, which won't affect the interior light maps, so I can't see any reason why making scene lighting border aware wouldn't work.

What's you opinion regarding dif recompile vs visual artifacts?

-John

#9 @John,

Personally i would love to nuke map2dif.. maybe even the whole interior code and rewrite it. But since that would take alot of a time and resources, we don't have that luxury.

It would indeed be a pain re-compiling all the .dif's... perhaps you can make use of the dummy spaces that the InteriorResource writes out, and say, write out an extra variable, saying "This is a good .dif with fixed lightmap borders", and if its not set (with old interiors), fixup the lightmap's on load, perhaps even re-save the interior.

#10 "dummy spaces"

This is exactly why I queried the community for a simple solution unknown to me. :) I'm unfamiliar with the dif format and didn't realize it had room for expansion without breaking compatibility, very cool.

Are these empty locations for future use or discontinued fields (would I need to worry about old difs with values in these locations)?

#11 Hmm... This is a very good fix. I'll have to consult with my coworkers - maybe it's something to put into HEAD. At the very least it would be nice to find a way for it to co-exist with older interiors. Nice work John!

#12 Thanks Ben. I have the Interior class loading both versions thanks to James' excellent recommendation (only took about 5 minutes). The dif actually stores the lightmap border size, so any border size including no border (size 0) can be loaded and saved.

Having used one of only four dummy slots I didn't want to waste it on a single U32, so I create an extended-lightmap block, which contains the lightmap border size and a new dummy slot for nesting blocks inside the lightmap block (again for future expansion).

Both old and new difs are compatible with the new Interior class, however the old Interior class is NOT compatible with newer difs, so I setup the lightmap block to only insert itself when the border > 0. This allows backwards compatible difs (for older TGE builds) to be built.

I'll start working on the scenelighting changes soon.

-John

#13 Nice job John.

#14 Thanks Josh,


Ok, I finally had a chance to get back to this. I've updated sceneLighting to factor in interior specific border sizes for the ambient and sunlight calculations. As I mentioned before this allows an updated TGE to transparently load old difs, new difs of the same border size, and new difs of differing border sizes.

This update has minimal changes and has worked fine for me, but I would like a few people to try and break it. Here are the patch files (for the engine and map2dif - run them from the torque directory using 'patch -p0 < TGE-_lm_fix.patch'):

Patch files are built for HEAD 7/25/2004 (always backup your files before applying patches!)

www.synapsegaming.com/content/linkedimages/TGE-engine_lm_fix.patch
www.synapsegaming.com/content/linkedimages/TGE-map2dif_lm_fix.patch


Let me know if there are any problems!

-John

#15 Ok quick update:

I've been running this change for a few weeks now and it looks solid - more importantly the interiors look great. From the improvement I think there were issues with neighboring light map bleeding into each other, that this also fixed.

I created docs outlining the necessary changes for this and the sunlight issue I posted a few months ago, here:

SG TGE fixes

I hope this helps someone out!

-John

#16 Nice work, John... Do you mind if this goes into HEAD?

#17 Thanks Ben,

Sure thing, go ahead and toss it into HEAD.

-John

#18 Alrighty, it's in HEAD.

#19 John,

Great update. I've noticed the purple and green as well and just tought my video card was playing tricks.

Does the sunlight fix do anything for us Lighting Pack owners?

*EDIT*
Answer:
If I would have read ALL of the posts above and the links they went too, I would have learned that YES, this does help out people who also installed the Lighting Pack.

Thanks,
Joe

#20 Ben, cool.

Joe, not a problem. :)