Light frustums different in DR and TDM

[stgatilov]

7 hours ago, duzenko said:

The d3 frustum is not air tight

If you want your volumetric light to behave the same way as projected lights, then you cannot use the matrix from BFG anyway.

[stgatilov]

One thing I don't understand is that Doom 3 projected lights don't have "light radius" spawnarg.

So, target/right/up define an infinite frustum which should be capped from the front and back by start/end parameters. However, if end-start vector is orthogonal to some light ray, then the start/end clipping plane from Doom 3 do not cap the frustum. In this case, the light volume becomes infinite without any diagnostic: the set of light planes does not bound a volume, and the light polytope has planar faces of size 128*1024 and is not closed.

[duzenko]

Let's do something with it already  

[stgatilov]

On 11/14/2021 at 11:32 AM, duzenko said:

Let's do something with it already  

I'd be glad to, but my minimalistic attempts to fix this have failed so far.
I guess I'll have to refactor the whole place a bit.

Also, I'm afraid hurrying up is a dangerous approach...
In the worst case it's better to postpone this problem until 2.11. That would mean I'll revert your fix for (far+near -> far), because it's better to have two different behaviors to deal with than to have three of them
 

[stgatilov]

I have implemented something, which should hopefully (after testing and bugfixing) be able to reproduce the behavior of both systems. Now it's time to test.

Is there any simple way to test the whole volume on the projected light?
I mean, ordinary testing against floor only shows light behavior on one planar section, and I'd like to see many sections at once. I know that this is exactly what "volumetric light" should achieve, but maybe there is some stupid way, like putting many small objects, or several transparent planes, or maybe grids...

[duzenko]

You could use the debug code in the volumetric render function that compares corner vertices. That and maybe compare with dr corners.

Maybe also use volumetric light to visualize the frustum and put 8 candles on frustum corners in dr

[OrbWeaver]

For my screenshot earlier I just did it the dumb way: duplicate the projected light several times, move each one up or down by some amount, and view all of the lights simultaneously projected onto a single surface.

[stgatilov]

I added grid of 16x16x16 unit cubes (distance = 8 between neighbors).
It takes ages to dmap, but works as intended.
I tried to convert it into a model: Obj export works fine in DR, but Ase export hangs... so for now I'm using the brush-made version.
UPDATE: Added test FM in svn rev 16387.

@duzenko, is there a way to visualize light frustums?
I see there is r_showLights, but it crashes somewhere inside OpenGL driver immediately after enabling it...
I need to verify that the BFG-style frustum that I have created indeed bounds the D3-style frustum.

[AluminumHaste]

That only took 35 seconds to dmap for me. Did you optimize it already?

Cool map.

[stgatilov]

Ok, I found one more issue on current TDM: the projected lights do light stuff outside their frustum.

The issue is very easy to see on the test map that I added, especially with "r_useLightScissors 0". With scissoring enabled, most of wrong spots go away, but some are still visible with obvious scissoring artefacts as you move around.

@duzenko has already noticed one such issue and committed a fix in svn rev 9640. Basically, he disabled lighting of "antiworld" (where divisor w<0).

First of all, he applied the fix only in one place, but the code for fetching projection/falloff is currently copy/pasted over 4 places (not counting new volumetric light shader, which also uses it). I extracted the code into 3 functions in a single header (svn rev 9645). Hopefully, now all fixes related to the current topic are applied universally.

Another problem is that there are many more bad areas where light works while it should not. Basically, both U and V texcoords on projection texture and fallof parameter can get out of [0..1] interval, in which case something weird happens. Perhaps it worked properly in Doom 3 and old TDM because textures were set to "clamp-to-zero" mode, but now they do not. So I added explicit if-s for the out-of-bounds case in svn rev 9646. After that I no longer see some magically lit zones outside frustum.

UPDATE: Images:

[duzenko]

2 hours ago, stgatilov said:

I added grid of 16x16x16 unit cubes (distance = 8 between neighbors).
It takes ages to dmap, but works as intended.
I tried to convert it into a model: Obj export works fine in DR, but Ase export hangs... so for now I'm using the brush-made version.
UPDATE: Added test FM in svn rev 16387.

@duzenko, is there a way to visualize light frustums?
I see there is r_showLights, but it crashes somewhere inside OpenGL driver immediately after enabling it...
I need to verify that the BFG-style frustum that I have created indeed bounds the D3-style frustum.

r_showLights was based on fixed-function GL and needs some love to make work on core profiles

It seems that volumetric is the easiest option right now

[stgatilov]

8 hours ago, duzenko said:

r_showLights was based on fixed-function GL and needs some love to make work on core profiles

I looked at the code, but it is not clear to me what's the problem.
I see some usage of frontend data (which is only a problem for SMP), and some common rendering calls (which use index/vertex buffers now), and nothing really deprecated.

I don't want to use volumetrics yet, because I want to be able to render different things: at least the polytope and the frustum separately.

[duzenko]

2 hours ago, stgatilov said:

I looked at the code, but it is not clear to me what's the problem.
I see some usage of frontend data (which is only a problem for SMP), and some common rendering calls (which use index/vertex buffers now), and nothing really deprecated.

Let me look into that

[duzenko]

16 hours ago, stgatilov said:

I added grid of 16x16x16 unit cubes (distance = 8 between neighbors).
It takes ages to dmap, but works as intended.
I tried to convert it into a model: Obj export works fine in DR, but Ase export hangs... so for now I'm using the brush-made version.
UPDATE: Added test FM in svn rev 16387.

 

Can you double check spotlight_normal2? It seems to have invalid start/end resulting in NaN in its matrices and debug asserts failing

{
"classname" "light"
"name" "spotlight_normal2"
"_color" "1 1 1"
"light_end" "200 0 -20"
"light_right" "50 0 0"
"light_start" "0 0 -20"
"light_target" "0 0 -100"
"light_up" "0 30 0"
"nodiffuse" "0"
"noshadows" "1"
"nospecular" "0"
"origin" "-4 -300 40"
"parallel" "0"
"texture" "lights/ambient_roundedsquare"
}

 

[stgatilov]

28 minutes ago, duzenko said:

Can you double check spotlight_normal2? It seems to have invalid start/end resulting in NaN in its matrices and debug asserts failing

This is the wrong light... but it seems to be too wrong
I'll fix it.

For now, you can set skipThisAssertion variable to true when debugger breaks at it (have to do it once on each run though).

[duzenko]

It seems as if the problem is with VBO but I can't see it

For now I added a fallback code for compatibility profiles

Completed: At revision: 9653  

[duzenko]

Hmm, I think I can see the problem

I fixed the wireframe and now looking at the filled triangles

...

At revision: 9654

[stgatilov]

On 11/21/2021 at 5:10 PM, duzenko said:

Hmm, I think I can see the problem
I fixed the wireframe and now looking at the filled triangles

Oh, thanks! It work perfectly now!
I have committed all my changes to SVN (revs 9657 - 9662).
 

First of all, I have implemented different code for constructing the light polytope (R_PolytopeSurfaceFrustumLike).
That's what @duzenko was complaining about long time ago (4888), but I could not understand what's the deal.

I have attached a patch which removes the "frustumTrisExact" hack.
@duzenko, could you please check how volumetric lights are doing with it and commit it if everything is OK?

To be honest, I'm not sure that I set proper orientation to windings/faces in R_PolytopeSurfaceFrustumLike.
Maybe normals look inside, and everything is broken now... need to test more

Second, I have committed the code which reproduces Doom 3 light projection/falloff behavior.
It needs setting "r_spotlightBehavior 0" before starting a map.

Since I cannot imagine how we tell all the mappers who tweaked spotlights in 2.05-2.09 that we decided to break their maps, I suppose we will do some behavior switch depending on e.g. "__spotlightBehavior__" spawnarg of worldspawn. That would allow both to save recent maps and to restore the old ones.

Speaking of r_showLights, I have added bit 8 which renders BFG-style light frustum.
I have verified that it properly bounds the light volume rendered by Doom 3.

P.S. Here you can see both frustums at the same time (I have underlined BFG frustum manually to make it more visible):

 

FrustumExact_removed.patch

[duzenko]

1 hour ago, stgatilov said:

Oh, thanks! It work perfectly now!
I have committed all my changes to SVN (revs 9657 - 9662).
 

First of all, I have implemented different code for constructing the light polytope (R_PolytopeSurfaceFrustumLike).
That's what @duzenko was complaining about long time ago (4888), but I could not understand what's the deal.

I have attached a patch which removes the "frustumTrisExact" hack.
@duzenko, could you please check how volumetric lights are doing with it and commit it if everything is OK?

To be honest, I'm not sure that I set proper orientation to windings/faces in R_PolytopeSurfaceFrustumLike.
Maybe normals look inside, and everything is broken now... need to test more

Second, I have committed the code which reproduces Doom 3 light projection/falloff behavior.
It needs setting "r_spotlightBehavior 0" before starting a map.

Since I cannot imagine how we tell all the mappers who tweaked spotlights in 2.05-2.09 that we decided to break their maps, I suppose we will do some behavior switch depending on e.g. "__spotlightBehavior__" spawnarg of worldspawn. That would allow both to save recent maps and to restore the old ones.

Speaking of r_showLights, I have added bit 8 which renders BFG-style light frustum.
I have verified that it properly bounds the light volume rendered by Doom 3.

P.S. Here you can see both frustums at the same time (I have underlined BFG frustum manually to make it more visible):

 

FrustumExact_removed.patch 3.08 kB · 0 downloads

Thank you very much, evidently your math expertise is a rare fortune for TDM

The frustumTri's do appear flipped sometimes. I think I can reuse the indices from my previous attempt here (since your vertex order is the same as in BFG frustum corners)

Here's a trivial normal test for latest svn

While cubeIndices results in

Committed to svn. You might want to refactor code just before my change as the indices get overwritten. I did not touch it as it's getting late here, bedtime for me

I'm not completely sure about the vertex orientation too. Volumetric seems to work for me now, but it's not a 100% proof.

Oh, and we still need to do something with DR

[stgatilov]

9 hours ago, duzenko said:

The frustumTri's do appear flipped sometimes. I think I can reuse the indices from my previous attempt here (since your vertex order is the same as in BFG frustum corners)

I have implemented different orientation testing code: it computes CCW normal of a windings and checks that it is directed the same way as the input plane it belongs to. Also, I fixed all differences, even checked that R_PolytopeSurfaceFrustumLike and R_PolytopeSurface produce windings of same orientations in all the cases of my test map.

[stgatilov]

There are sad news too.

I started looking how various TDM versions work on the test map, and it does not match the theory (and does not match the behavior on the current SVN). I'll post a detailed review...

[duzenko]

I think the BFG code was disabled by default for a while after having been added

Can't remember when the cvar controlling that was toggled

[stgatilov]

19 hours ago, duzenko said:

I think the BFG code was disabled by default for a while after having been added
Can't remember when the cvar controlling that was toggled

Yes, but unfortunately you enabled it in 2.08.

Basically, all TDM versions from 2.00 to 2.07 work exactly the same as the current code with "r_spotlightBehavior 0".
Well... except for the case with unbounded light polytope, which I specifically guarded against. This case is too bad to exist: Doom 3 really shows infinite light volume for it

TDM versions 2.08 and 2.09 work exactly like BFG code with 1 / (far + near) replaced with 1 / far. So this is not vanilla BFG behavior, and thus does not match the current SVN with "r_spotlightBehavior 1".

This is a bit different from what I expected...
I do like BFG behavior more than D3 one. It makes more sense and does not have the weird "unbounded polytope" case.
However, behavior from 2.08 and 2.09 is a bit different and it does not make sense mathematically. And that's only two versions: not too many FMs made with it.

I'm once again leaning towards simply restoring the old behavior...

[stgatilov]

Ok, here is how TDM 2.08 / 2.09 works (i.e. D3BFG with zScale replaced).
There are two matrices: one is used for lighting in shader, the other one is used for culling.

• The BFG-style matrix (which is used for culling) is not affected: it is exactly the same as in D3BFG. It defines a frustum going from distance = "near" (depth = 0) to distance = "near" + "far" (depth = 1).
• The Doom 3 matrix (which is used for lighting in shader) is changed: falloff parameter changes from 0 at distance = "near" to 1 at distance ~=~ "far" (instead of having 1 at distance = "far" + "near" in D3BFG).

So, the culling frustum is a bit larger than shading frustum, which is OK (bad situation is when culling frustum is smaller).
Also, falloff texture applies from "near" to approximately "far", almost like in the original Doom 3.

More exactly, the back distance of the frustum is:    far   +   near^2 / (far + near)
Just to remind: "near" is where "light_start" spawnarg points, and "far" is where "light_end" spawnarg points.
Obviously, the additional term is negligible in most of the real use cases.

[stgatilov]

Switched the default behavior to the old one (r_spotlightBehavior 0) on code SVN.
I'll do some comparison testing on real FMs, but most likely that's the end of the story.