Game Development Community

Error while lighting interior on Mac [TGE 1.5

by asmaloney (Andy) · in Torque Game Engine · 12/27/2006 (4:04 am) · 8 replies

I'm trying to light a mission on the Mac [PPC] using 1.5 - it works fine on Windows. I am getting the following error:

Starting Synapse Gaming Lighting Pack scene lighting...
    Lighting interior object 1 of 7 (base/data/interiors/xxx.dif)...
    Object lighting complete (898.114 seconds)
    Lighting interior object 2 of 7 (base/data/interiors/xxx2.dif)...
    Object lighting complete (407.511 seconds)
    Lighting interior object 3 of 7 (base/data/interiors/buildings2.dif)...
    Object lighting complete (102.621 seconds)
    Lighting interior object 4 of 7 (base/data/interiors/buildings4.dif)...
    Object lighting complete (43.498 seconds)
    Lighting interior object 5 of 7 (base/data/interiors/buildings3.dif)...

Fatal: (/Users/maloney/Torque/xcode/../engine/lightingSystem/sgSceneLightingInterior.cc @ 143) Light map extents exceeded bitmap size!

[yes those times are real :-)]

Could someone please explain what this error means? I don't have any experience with TLK or difs.

Thanks!

#1
12/28/2006 (2:35 pm)
The assert is used to make sure the lighting system doesn't try to access data outside of the light map's boundaries.

When the debugger halts the program what are the values of lmborder, surface.mapSizeX, surface.mapSizeY, surface.mapOffsetX, and surface.mapOffsetY?
#2
12/28/2006 (5:48 pm)
Thanks for the quick answer John. I guess I should have been more specific with my question - the error message is clear :-)

I should have asked: What conditions could cause this assert to fail? Is it a problem with the model itself, the textures, or the lights in the mission? Why would it only be a problem on Mac OS X and not Windows?

lmborder = 10
surface.mapSizeX = 242
surface.mapSizeY = 10
surface.mapOffsetX = 10
surface.mapOffsetY = 10

lm width and height are 256

xlen is 262 which is why it's borked.
#3
12/29/2006 (8:13 pm)
Try recompiling your difs with map2dif 1.5 (this will certainly help the relight times), the data coming from the dif is causing the problem.

Btw: are you using a modified or stock map2dif?
#4
12/30/2006 (7:25 am)
Unfortunately I don't have access to the map files - I've just been given the difs and other assets.

It turns out that on an Intel Mac it works, but not PPC. Is it an endian issue?
#5
12/30/2006 (10:53 am)
I *think* for that to be the case, either the big/little endian compatibility would have been broken in the past, be broken now, or be broken on both platforms when using older assets (ie: the file format changed).

Assets work cross platform in 1.5 and in previous versions, and many assets from previous versions are used with 1.5.


Try performing the assert check in the end of Interior::read to see if the data is coming off of the disk in a bad format, and what the values for the bad interior/surface combinations are on Windows and Mac Intel.

This is a good check because it's possible the data is being read properly and corrupted later on during runtime.


Also try running the mission against a clean 1.5 build.
#6
12/30/2006 (12:39 pm)
Assuming I did this correctly:
if ( (stream.getStatus() == Stream::Ok ) )
	{
		S32 xlen, ylen, xoff, yoff;
		S32 lmborder = getLightMapBorderSize();

		for ( U32 i = 0; i < getSurfaceCount(); i++ )
		{
			const Surface &surface = getSurface( i );
			
			xlen = surface.mapSizeX + (lmborder * 2);
			ylen = surface.mapSizeY + (lmborder * 2);
			xoff = surface.mapOffsetX - lmborder;
			yoff = surface.mapOffsetY - lmborder;

			GBitmap *lm = mLightmaps[getNormalLMapIndex(i)];
			AssertFatal((lm), "Why was there no base light map??");

			AssertFatal((
				((xoff >= 0) && ((xlen + xoff) < lm->getWidth())) &&
				((yoff >= 0) && ((ylen + yoff) < lm->getHeight()))), "Light map extents exceeded bitmap size!");
		}
	}

It asserts with the same dif on Interior::read(). [Much better place for that check - immediate instead of waiting half an hour to get there...]

That's kinda strange... I don't see anything in the dif format which indicates 'endian-ness', and all the other difs [presumably done at around the same time] seem to be working fine.
#7
12/30/2006 (6:12 pm)
Quote:It turns out that on an Intel Mac it works, but not PPC.

I may have spoken too soon... I don't have an Intel Mac, so I have to gather info through others. Let me regroup and try to understand the code a little better and then come back...
#8
01/10/2007 (7:57 am)
Thought I would just close this thread off. It was decided to remove the mission containing this dif since it had other issues anyways.

Thanks John!