WARNING: baseLightProject invert failed

[grayman]

Does anyone know what this warning means?

I'm getting spammed with it using the SVN Windows 64bit exe.

Thanks.

[duzenko]

14 hours ago, grayman said:

Does anyone know what this warning means?

I'm getting spammed with it using the SVN Windows 64bit exe.

Thanks.

That looks like a bug

I don't recall seeing this yet.

Does it happen in your WIP map?

[grayman]

Yes.

I tried the Training Mission and WS5 for a few mins and there was no spam.

If this has something to do with projected lights, I could try isolating it. I use a lot of projected lights due to lightning in the mission. (I tried Somewhere Above the City, which also has lightning, and there was no spam.)

 

Edit: Not caused by projected lights. I removed all of them, and the spam still appeared.

[duzenko]

I would take a look at a simple repro case if you have one

[grayman]

I don't have one.

Is the warning part of the lighting code, or something else? I need to know what to focus on when creating a test case.

[duzenko]

2 minutes ago, grayman said:

I don't have one.

Is the warning part of the lighting code, or something else? I need to know what to focus on when creating a test case.

Yes, it's a part of D3 BFG lighting code merged into TDM this year

Namely the R_DeriveLightData() function.
 

[grayman]

The problem is caused by the lightning/thunder entity (func_fx using the spawnarg 'fx/thunder.fx').

I'll try to create a test map.

[grayman]

Test map attached. Notice that the sky lights up, but none of the rooms light up.

I might remove all the relays in the end, but this version with the relays shows the warning spam.

lightning.zip

[duzenko]

First impression looks like 32bit precision overflow

Do you need the light to be 999999 units in size?

If so, try 2^20 instead of 999999 just to see if that helps.

Are you trying to simulate a parallel light here by making the point light that huge?

I think instead of inversing the near-degenerate matrix we could initialize it alternatively but my linear algebra kungfu is lame.

@stgatilov?

As a dirty work around we could mark specific lights to not emit this warning but I think it's there in the first place to avoid light abuse like this.

[grayman]

This is stock TDM, nothing special done by me.

[stgatilov]

There are many options what to do.

1. Reduce light radius of all thunders from 999999 to 99999. It would pass the tolerance then, but would still be 10x larger than size of normal level according to ID software.
2. Reduce tolerance on determinant. But to be honest, it is already very low (1e-16), so matrix inversion will more likely return garbage for almost-singular matrix than report error for properly invertible one.
3. Implement special case --- inversion of diagonal matrix. In such case, no tolerances are necessary. Of course, if someone adds rotation to such a gigantic light, it will stop working.

 

 

[stgatilov]

BTW, added issue 5072 for this.

[nbohr1more]

AFAIK, Doom 3 never had "true" Parallel lights. When you use the parallel keyword, you are forcing an absurd light radius.

I haven't checked the recent code-base to see if this has been substantially altered since Doom 3.

[duzenko]

3 hours ago, stgatilov said:

There are many options what to do.

1. Reduce light radius of all thunders from 999999 to 99999. It would pass the tolerance then, but would still be 10x larger than size of normal level according to ID software.
2. Reduce tolerance on determinant. But to be honest, it is already very low (1e-16), so matrix inversion will more likely return garbage for almost-singular matrix than report error for properly invertible one.
3. Implement special case --- inversion of diagonal matrix. In such case, no tolerances are necessary. Of course, if someone adds rotation to such a gigantic light, it will stop working.

 

 

4. Switch the 'lightning' light to parallel?

Now wait a minute

Isn't this an ambient light essentially?

I mean, does it need shadows, or direction?

If it does need direction, it should be parallel. If it does not need both, it can be ambient.

Alternatively, we could use the current world size instead of the hardcoded 999999

One more option, the lightning could be implemented via a screen filter, or something

 

[nbohr1more]

In Sotha's mission "The Transaction" the lightning has shadows and you can hide in them when the lightning flashes.

If Sotha used the default entity then this would also have shadows.

[duzenko]

8 minutes ago, nbohr1more said:

In Sotha's mission "The Transaction" the lightning has shadows and you can hide in them when the lightning flashes.

If Sotha used the default entity then this would also have shadows.

Correct me if I'm wrong but the default lightning has origin (0,0,0). The shadows that it's casting will look like nothing you see in real world.

@Sotha?

[nbohr1more]

Again, as I recall, Id Software did a hack to make the light "look parallel" by forcing it to always be "far away" even if the actual

entity is close to the surface. It simulates attributes of moon\sun lighting but short-cuts the need to actually "exist" in a distant location.

[nbohr1more]

Here we go:

 

https://www.iddevnet.com/doom3/editor_light.html

 

By marking the light as parallel, the light acts as if the center is extruded out to infinity. All the shadows will go in the same direction, and all the highlights in the bumps will face the same direction. This is very handy for creating sunlight.

 

[nbohr1more]

I'll bet that if you follow the entity inheritance for the lightning entity to the template light entity that it is created from,

you will find the parallel keyword there

 

Edit: I lost that bet...

 

We would need to parse this fx def:

darkmod/fx/thunder.fx

[grayman]

I reduced each 999999 to 99999 and the lightning works correctly now, with no warning spam.

I haven't committed the change; whoever's looking at the math might come up with something better.

Released maps that use fx/thunder.fx should get tested during beta. There are at least eight.

 

 

[stgatilov]

33 minutes ago, grayman said:

I reduced each 999999 to 99999 and the lightning works correctly now, with no warning spam.

I haven't committed the change; whoever's looking at the math might come up with something better.

In my opinion that's the best solution for now.

 

Quote

Released maps that use fx/thunder.fx should get tested during beta. There are at least eight.

Ehm... 12 maps by January 2019:

ac2\ac2.pk4 -> maps/ac2.map: 2
antr\antr.pk4 -> maps/antr.map: 1
briarwood\briarwood.pk4 -> maps/briarwoodcathedral.map: 2
closemouthed_shadows\closemouthed_shadows.pk4 -> maps/closemouthed_shadows.map: 1
deceptiveshadowsv1_2\deceptiveshadowsv1_2.pk4 -> maps/deceptiveshadows.map: 2
nhat3\nhat3.pk4 -> maps/anoott.map: 1
nhat3\nhat3.pk4 -> maps/forest.map: 1
siegeshop\siegeshop.pk4 -> maps/siegeshop.map: 2
somewhere1_1\somewhere1_1.pk4 -> maps/somewhere.map: 11
springcleaning\springcleaning.pk4 -> maps/sc.map: 1
storm\storm.pk4 -> maps/storm.map: 2
transaction\transaction.pk4 -> maps/transaction.map: 2

 

[duzenko]

The Transaction map shows the same problem - console warnings and no lightning effect (except for skybox)

[stgatilov]

I committed the simple fix in svn rev 15746.