Bounce lighting sometimes fails when phong shading is used

[BoraxMan94]

Using blarghrad on Linux for my map, I noted that sometimes bounce lighting would fail. I found that "CollectLight();" would return "nan" and the map would come out black. Turning bounce lighting off fixed the problem, AS DID removing the use of phong shading.

This was evident when blarghrad was run with the '-v' parameter. The bounce added was 'nan'.

9740 faces
651801 square feet
31209 patches after subdivision
1541 direct lights: 75 entity, 1466 surface
0...1...2...3...4...5...6...7...8...9... (12)
0...1...2...3...4...5...6...7...8...9... (46)
transfer lists: 200.9 megs
bounce:0 added:-nan
bounce:1 added:-nan
0...1...2...3...4...5...6...
************ ERROR ************
SampleTriangulation: no points

I did some debugging to find where the floating point operation failed and also some trial and error to see what maps failed and what didn't. It seems that some floating point operations failed even during successful light runs during my tests. Also did some digging using the ghidra decompiler on the source, and have been able to resolve SOME of the issues. I still get the error

9740 faces
651801 square feet
31209 patches after subdivision
1542 direct lights: 76 entity, 1466 surface
0...1...2...3...4...5...6...7...8...9... (13)
0...1...2...3...4...5...6...7...8...9... (47)
transfer lists: 201.8 megs
bounce:0 added:635464704.000000
bounce:1 added:182857344.000000
0...1...2...3...4...5...6...
************ ERROR ************
SampleTriangulation: no points

at the end, but some test cases which failed, now pass, and the bounces are added correctly (sort of).

After some digging, I've found some issues with the function void maybePhongSomething(int facenum, const vec3_t& center, const vec3_t& plane_normal, vec3_t& out_vec_param_4);

All these issues are with that function in patch.cpp

The following code I think was meant to swap the values of the two vectors, maxs and mins around if the conditional was true.

    if ((maxs.data[local_EBP_165] - mins.data[local_EBP_165]) < (maxs.data[local_98] - mins.data[local_98])) {

        // TODO this looks wrong
        float ftmp = maxs.data[local_EBP_165];
        float ftmp2 = mins.data[local_EBP_165];
        float fVar9 = mins.data[local_98];
        maxs.data[local_98] = maxs.data[local_98];
        maxs.data[local_EBP_165] = ftmp;
        mins.data[local_98] = fVar9;
        mins.data[local_EBP_165] = ftmp2;

        pdVar13 = local_98;
        local_98 = local_EBP_165;
    }

Line 375. you have
if (local_48.data[local_98] == (afStack96.data[local_98] - local_18.data[local_98]) * fVar4 - afStack96.data[local_98])

I got the following from ghidra
if((fVar3 || fVar4) != (fVar3 == fVar4)) {

Ghidra also gives another line before line 374, fVar4 = local_6c[(int)local_98 + 3] - (local_6c[(int)local_98 + 3] - local_18[(int)local_98]) * fVar4;

Line 379
fVar3 = (fVar3 - local_6c.data[local_98]) / (fVar3 - (afStack96.data[local_98] - (afStack96.data[local_98] - local_18.data[local_98]) * fVar4));
This line is a problem. Sometimes returns infinity. The problem is the divisor sometimes evaluates to 0.

I got the following from ghidra when I decompiled Arghrad 3
fVar3 = (fVar3 - local_6c.data[local_98]) / (fVar3 - fVar4);

I've attached a zip of my version, which has the changes I made and some comments. There is a commented out function called "phun" in patches.cpp which is the ghidra output I got.

Hope this helps!

borax_blargrad.zip

[BoraxMan94]

I'm not sure if my fixes help, as the phong shading now comes out a little weird. But if one thing helps, is that when I set the texture scale to 0.5, it seems to cause the "nan" phong result, and setting it something else can fix it.