stgatilov

Not exactly, since you have to do the conversion. But one can follow the code in current SVN, and see what R_ComputeSpotLightProjectionMatrix puts into "oldProject" under "r_spotlightBehavior 1". Although I'd say it must be checked against the reference (i.e. check the visual result against Doom 3 BFG).

I checked a few missions which show up in my lists of "weird" ones, and the projected lights exactly match right now (compared to 2.00, 2.04, 2.05 --- whatever is necessary to boot FM). Regarding DarkRadiant, the frustum it shows also matches the old behavior of Doom 3 and TDM. I'd say it would be great to do the following in DR: Warn mappers when they try to create a projected light with unbounded frustum. Such lights will not work well. They'd better know it immediately. If Doom 3 BFG mapping is a real thing and DR needs to support it, then you'll need to implement different computation specifically for D3BFG (well, unless you have already).

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.

I'm greatly impressed by the speed of DR development! One minor thing is missing from bugtracker/changelog: new Game Connection GUI Everyone can find it in the "Map" menu...

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.

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...

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...

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.

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

Made 2.09b the default version. I hope at least a few people have installed and played it I'll finish the release process tomorrow (tags, source, pdb, etc.)

That's because rats carry diseases, so even after one touch of dead rat you become too weak to lift it Seriously, this is known issue that will not happen in 2.10, one way or another.

So... does TDM work on it without issues?

Yet another (and the final) hotfix release for 2.09 is available. You can obtain it with tdm_installer. Make sure you check "Get custom version" on the first page, then choose release209b on the second page. If you need 32-bit binary, you can download it as additional archive here. After a very short testing, this hotfix will become the new "default" in tdm_installer, unless any serious issues are detected. Contrary to the usual case, savegames are fully compatible all ways between original 2.09 release and 2.09a and 2.09b hotfix releases. You don't need to finish playing current mission in order to update and even rollback in case of any issues. Here is the list of changes compared to the 2.09a (mainly GL issues on AMD): * Fixed a bug causing black screen instead of main menu with music playing (thread). This problem happened on AMD GPUs and was previously circumvented by setting "r_glCoreProfile 0" in config file. This workaround is no longer necessary. * Fixed crash when new shader is loaded during gameplay (5012). This problem happened on AMD GPUs and could be previously circumvented by setting "com_smp 0", although I'm not sure it ever happened in the wild. Anyway, the workaround is no longer necessary. * Use windowed 800x600 mode as "safe mode" for renderer. It can help avoid initialization error in the rare case the game cannot do ChangeDisplaySettings (related thread). * Removed [cleanup] button from the main menu (thread). Remaining known problems: * The game does not start on old AMD GPUs (TeraScale 1) despite them supporting GL 3.3 (thread). No workaround known. * The game looks corrupted starting at the main menu on some Linux AMD drivers (thread). Workaround: set Color Precision to 32 bits.

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).

New version is available: dev16390-9648

If you are using TortoiseSVN Show Log on the repo, then you should use the checkboxes "Show All" at the bottom. You can see all revisions back to 5052 (I guess you can see earlier stuff too somehow).

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.

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:

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.

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...

Ooops Most likely I'll look into it somewhere during beta-testing. In the worst case I can just allow larger force on rats, so that player could carry rats, albeit with swinging issues... or revert to the old code for 2.10. But please remind me about it so that I don't forget!

Look here: https://wiki.thedarkmod.com/index.php?title=Setting_Reverb_Data_of_Rooms_(EAX) late_reverb_delay must be in range [0, 0.1]. And I think other options are pretty high too. What if you set these settings to zero? Do you hear the difference?

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

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.

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