Relight times

#1 Wow, I've never seen anything take that long - not even an entire mission.

The two biggest causes of performance loss are; using a debug build (which is easy to accidentally do), and increasing the interior lighting scale.

Oh, I also noticed that using VC6 and GCC provides *way* better performance than VC7 *Standard* - apparently VC7 Standard performs no optimization (at least none worth speaking of).

Are you using Xcode? Xcode handles debug/release builds differently than any other dev env, so it's easy to get an Xcode build out of whack.

Let me know if any of these thing look like the culprit!

-John

#2 I use VC6 and build with the release version always.
I set lightGeometryScale at 32 for LOD_0 and 64 for LOD_1 (but I had been doing this for awhile and the test interiors were identical--just not as many of them).

When you say "increasing" the lighting scale, do you mean lowering the scale number? I thought the lower the number the more texels in the lightmap...is this correct?

Prior to yesterday, the relight time for the entire mission was around 5 minutes total. If I made changes to an interior, it seemed that the relight only occurred for that new object. Now all interiors are being relit whether they have changed or not. Hmmm, a mystery

#3

Quote: Wow, I've never seen anything take that long - not even an entire mission.

Thats cause you never seen Desmonds Interiors! :)

Matt

#4 "When you say "increasing" the lighting scale, do you mean lowering the scale number? I thought the lower the number the more texels in the lightmap...is this correct?"

Yup, and using 32 and 64 should create *really* small light maps, so I don't think that's a problem.


"If I made changes to an interior, it seemed that the relight only occurred for that new object"

There are two types of scene relighting in the Lighting Pack; the standard TGE relighting which relights the whole scene (this is always used during a relight on mission load), and filtered relighting which relights the interiors that are close to the camera (all other interiors turn black).


Do you have a copy of the faster mission and interiors (in a cvs or svn rep)? Try comparing those files to see what's different. Also, did you recently change any (or all) of the light datablock lighting models - specifically from the Advanced model to something else?

-John

#5 Hey Matt,

"Thats cause you never seen Desminds Interiors!"

Nice! :)

Btw: awesome work on those static objects (especially the lion statues) - very cool stuff.

-John

#6 @John,

"filtered relighting which relights the interiors that are close to the camera (all other interiors turn black)."

I'm getting more than just the TGE relighting on mission load; on mission load I'm seeing the sgLighting do a relight of all interiors just like the TGE lighting (except much longer)...not just filtered lighting.

Starting TGE based scene lighting...
Starting Synapse Gaming Lighting Pack scene lighting...

I ran this with the DEBUG executable and got the following:

*** Phase 3: Scene Lighting
Warning: (c:\dev\hv_sg13rad\engine\scenegraph\scenegraph.cc @ 818) ZoneManagers are only allowed to belong to one and only one zone!

Could this be bogging down the lighting process?

*************************************************************************

I took out all the plants and other models and the relight times for all the interiors are back to where they were (about 10 seconds per interior during the sg lighting portion).

So, have I reached some magic limit on models that is mucking with the lighting process?

Or, do I need to turn off the "receiveSunlight" and receiveMLLighting" options and turn on the self-illumination or customAmbientLighting for all models? If the answer is yes to these, what are implications for lighting times for either self-illumination or customAmbientLighting?

*************************************************************************

And, what does receiveLMLighting mean exactly? Does this increase the size the ml file? Are lightmaps for models stored in the ml file?

*************************************************************************
Further testing:

1. Lighting went fine after removing all models and staticLights (lightmap file = 1328KB)

2. Put the models back in after changing all settings to NOT receiveSunlight and NOT receiveMLLIghting-->just customAmbientLighting at "0.250000 0.180000 0.150000 1.000000"
-- Lighting went fine (approx. 10 sec per interior)...but the models are fairly dark
-- No staticLights
-- (lightmap file = 1354KB)

3. Put the staticLights in and the lighting process doesn't even start for the TGE lighting (I made sure all the dataBlocks were static before testing this).

#7 I meant that the Lighting Pack scene lighting is the same as TGE's in the sense that it lights all interiors (same as TGE scene lighting, but different from the Lighting Pack's filtered lighting which only relights interiors near the camera).


ReceiveSunlight and receiveMLLighting are dynamic lighting options that are calculated in real-time, and are ignored during mission lighting.

Quote:I took out all the plants and other models and the relight times for all the interiors are back to where they were (about 10 seconds per interior during the sg lighting portion).

So, have I reached some magic limit on models that is mucking with the lighting process?

Just to verify; the static lights were still in the mission, right?

There's no limit to the number of static objects the Lighting Pack can use as shadow casters, but this does bring up an interesting point - were any of the static objects added or changed right before the problem started? A concave collision mesh on one of the objects, or a large number of collision meshes on an object (like using TGE 1.4's unlimited collision meshes), or a complex collision mesh (> 24 polys) could bog down the lighting process.

Starting with the slow mission try removing static objects that use the same DTS file testing the relight as you go - for instance if I were working on the TGE demo I would remove all objects using the 'tree2.dts' file, test the relight, then remove all objects using the 'campfire.dts' file, and repeat until the lighting speed increased dramatically. This should point to the culprit, then we can work out why the model is causing a problem (though it's probably one of the three things I posted above; convex collision mesh, too many collision meshes, or complex collision mesh).

-John

#8 Btw: were the lighting models changed right before the problem started (from the advanced model to another one)?

-John

#9 Thanks John,
Yes, I added a rather complex DTS but I don't know what the shape of the collision mesh is--I will pull that one to see if that impacts the problem....update: this did not fix the problem.

I haven't changed the lighting model (using the advanced).

However, look at my sequence of testing three posts up...
Test 1 had: only interiors (no models or lights) --> relight ok
Test 2 had: interiors and models (no lights) -->relight ok
Test 3 had: interiors, models and lights --->bogged down; didn't even start the relight process

Test 4:
I removed all but four lights (left interiors and models) and lighting proceeded ok (the lighting times for sg were 26 seconds instead of the 10 I saw before--this raises another question: there are variances in the lighting times for TGE process but the sg lighting times appear to all be about the same amount).

Test 5:
I removed all the lights again (only interiors; no models) and the TGE lighting went well and the sgLighting is going at about 13 seconds per interior. Can this be a processor issue? A variation from 10 to 13 to 26 secondsto five minutes per interior????What's going on here?
I'm going to try this on another platform tomorrow.

#10 The Lighting Pack lights and the TGE sun have very different scene lighting architectures, so I'm not surprised that the relight times are different, especially if you're using zones in your interiors.

What is the relight time when you keep all of the lights and interiors in the scene but remove the static objects?

#11 Ok, I solved this by globally searching for the enable flag for all lights and setting it to 0. Then I only turn on 5 or 6 at a time in the world with the filtered relight. I guess this is what you intended to begin with...just took me a bit to catch on. But it was a good exercise on pushing the envelope. Thanks for your insights and outstanding lighting pack--I'm sure I haven't touched the rest of the iceberg of what it can do.

I believe I fixed the zone issue also. That should be stock--it's been a problem from day one.

#12 We've been plagued by this too, we haven't solved it but found a few things that can help.

1. reduce the lightmap border as much as you can.
2. improved Interior::castRay_r
3. improved ShadowVolumeBsp::recyclePoly
4. improved ShadowVolumeBsp::clipPoly
5. improved ShadowVoumeBsp::getPolySurfaceArea

all of this combined helped the lighting in one scene go from 425 to 45 seconds.

#13 Hi Cameron,

Which of those changes made the biggest improvement for you (I'm guessing the border size)? Can you provide some info from your scene like the number of static lights, the number of interiors, the interior lighting scales, and the lighting models.


If someone can provide me with an unusually slow scene I'll look into the performance.

Right now the most complex scene I have uses 15 zoned static lights setup to simulate radiosity in an interior. The interior has a very high lexel density (the lighting scale is set to 4.0) and the border size is set to 10 (the TGE default). The scene performs a full relight in 5.4 seconds and only 4 seconds are spent lighting the interior with the static lights (I'm running an AMD Athlon 64 2800+).

-John

#14 Yes, reducing the border was the big one. but the others helped out too. castRay_r was getting called 120+ million times to light the scene. by removing some recursion and such i was able to get it down to 25 million calls. i like this because it helps game play as well.

as far as our scene goes its about 45 static lights with 6 or interiors. a couple interiors are slightly complex. i think in total it ends up being around 120 megs of light maps.

#15 I've looked into adding an early-out for Interior::castRay_r too, but it caused problems with interior self-shadowing under certain conditions.

What lighting models are you using, maybe I can pinpoint a performance hit on one of the models?

#16 Here's the modified castRay_r, i think its almost twice as fast as before:

bool Interior::castRay_r(U16      node,
                         U16      planeIndex,
                         const Point3F& s,
                         const Point3F& e,
                         RayInfo*       info)
{
    while (isBSPLeafIndex(node) == false)
    {
        const IBSPNode& rNode = mBSPNodes[node];
        const PlaneF& rPlane  = getPlane(rNode.planeIndex);

        bool f = false, b = false;

        F32 distS = (rPlane.x * s.x + rPlane.y * s.y + rPlane.z * s.z) + rPlane.d;

        if (distS >= 0.005f)                 
            f = true;
        else if (distS <= -0.005f)           
            b = true;

        F32 distE = (rPlane.x * e.x + rPlane.y * e.y + rPlane.z * e.z) + rPlane.d;

        if (distE >= 0.005f)                 
        {
            if( b ) {
				Point3F ip;
				F32 t = -distS / ( distE - distS );
				ip.x = s.x + (e.x-s.x)*t;
				ip.y = s.y + (e.y-s.y)*t;
				ip.z = s.z + (e.z-s.z)*t;

                if (castRay_r(rNode.backIndex, planeIndex, s, ip, info))
                    return true;
                return castRay_r(rNode.frontIndex, rNode.planeIndex, ip, e, info);
            }

            f = true;
        }
        else if (distE <= -0.005f)           
        {
            if( f )
            {
                Point3F ip;
				F32 t = distS / ( distS - distE );
				ip.x = s.x + (e.x-s.x)*t;
				ip.y = s.y + (e.y-s.y)*t;
				ip.z = s.z + (e.z-s.z)*t;

                if (castRay_r(rNode.frontIndex, planeIndex, s, ip, info))
                    return true;
                return castRay_r(rNode.backIndex, rNode.planeIndex, ip, e, info);
            }

            b = true;
        }

        if( f )
            node = rNode.frontIndex;
        else if( b )
            node = rNode.backIndex;
        else
        {
            // Line lies on the plane
            if (isBSPLeafIndex(rNode.backIndex) == false) {
                if (castRay_r(rNode.backIndex, planeIndex, s, e, info))
                    return true;
            }
            if (isBSPLeafIndex(rNode.frontIndex) == false) {
                if (castRay_r(rNode.frontIndex, planeIndex, s, e, info))
                    return true;
            }
            return false;
        }
    }

as far lighting model goes we're using inverse squared.

#17 Inverse square, yup that sounds familiar. I have an update that should give you a performance boost. It's been in testing for a while and so far seems solid enough that you can try it out.

Here are the changes:

In the file "engine/synapseGaming/contentPacks/lightingPack/sgLightMap.cc" make the following changes...

At line 18 add the following:
[i]
/// the objects used when casting shadows.
//#define SG_SHADOW_OBJECT_MASK	(TerrainObjectType | InteriorObjectType | StaticTSObjectType)
#define SG_SHADOW_OBJECT_MASK	sgShadowCasterObjectType

[b]#define SG_MIN_LEXEL_INTENSITY	0.0039215f[/b]

/// used to show the total lighting time by object type.
U32 sgInteriorLightMapTime = 0;
[/i]

At lines 363 [b]and[/b] 698 change the following:
[i]
if(allowdiffuse && ((diffuse.red > 0.0f) || (diffuse.green > 0.0f) || (diffuse.blue > 0.0f)))
[/i]
to:
[i][b]
if(allowdiffuse && ((diffuse.red > SG_MIN_LEXEL_INTENSITY) || (diffuse.green > SG_MIN_LEXEL_INTENSITY) || (diffuse.blue > SG_MIN_LEXEL_INTENSITY)))
[/b][/i]

Some of the lighting models never reach an intensity of 0.0f creating a lot of extra processing. The update cuts lighting off at (1.0f / 255.0f), which is the level that light is no longer visible (due to integer precision). This code is processed before the shadow calculation, so this will seriously minimize unnecessary processing.

Let me know if this helps!

#18 @Cameron
How do you handle the isBSPSolidLeaf nodes?

Also, I'm getting this error "error C2166: l-value specifies const object"
at the following section:

if( f )            
	        node = rNode.frontIndex;        
	   else if( b )            
	        node = rNode.backIndex;

@John
Which lighting model is the default and where would I change the model?

#19 The 'Original Stock' lighting model is the default (named because of its similarity to the stock TGE lighting model).

The Advanced lighting model is the only model I can say with 100% certainty is not affected by this update, meaning that if you're using any of the other models the above code will likely boost performance.

If you guys try this out let me know if and how much it helped.

[Edit]You can change the lighting model in the light editor.

#20 I think I'm using the advanced but can't remember how I set that.