stgatilov

There is no frustum in Doom 3, there is a set of planes. And as a set of planes, it has no issues. I'm pretty sure the code to compute vertices can be modified to fix the problem. But it is not clear how important they are.

Maybe try to switch between fullscreen / windowed? Do you have several monitors or something extraordinary about desktop/monitor/mouse?

Yes, indeed. In the worst case you can find always source code for a preset, copy all its attributes to your EFX file, then edit them as you see fit. But according to wiki article, you can override selected properties by writing them after preset line.

I think if we want to restore Doom 3 behavior, we should revert that change and remove BFG-style light matrices. That would make life much easier in the future. Before the change, there was one matrix stored in light. After the change, there are three matrices, two of which are inverse to each other. Now if I try to reproduce old behavior but retain the new BFG matrices, then the two matrices would become different: one would store actual light projection data, the other one will represent some bounding frustum. I imagine that would be endless source of confusion, and will cause similar problems in the future in case someone decides to touch this code. If we remove both BFG-style projection matrices, then everything will be simple again.

Not really. In fact, my check in case 3 is wrong: the falloff is different when S->E is not collinear to normal vector (N = R x U), not the target (T) one. Basically, almost all cases from p.2 are also affected, i.e. I cannot reproduce their falloff behavior with BFG code. That includes maps: Basically, tons of FMs are affected. And there is no way to reproduce their falloff behavior from TDM 2.04 with current matrix-based code. Some of them were released after 2.05, so they should work as intended now (and will stop working so). spotlights_SE_N_noncollinear.txt

I fixed the issue in svn rev 9643. For the previous dev. build, I fixed some weird behavior which looked like a bug, but it turned out that some code was working only thanks to that weird behavior, and hence it broke. Here is the difference between working and broken maps: If .map file has "name" spawnarg set on the worldspawn, then the map loading was broken. If .map file does not have "name" spawnarg on worldspawn, then it map loaded fine. Of course, some existing FMs (e.g. Window of Opportunity) have "name" spawnarg, so that was a serious issue. The next dev build should work fine in all cases.

If you read the whole topic, you'll know that 2.08 does not work. 2.07 is the latest version which works.

Let me be frank: I have absolutely no idea what's wrong and where to search. We can of course try to investigate it, but most likely it will take a lot of time and effort, without any guarantee of success (we can find nothing, or find something that we won't be able to change anyway). Indeed, it would be great to make TDM work on GPUs of your class because they formally support minimum required GL version, but I'm not sure you want to go this route without much hope for success.

It applies force equal to some hard-coded ratio (less than 1) multiplied by weight of the body. You will have the same success as with a rat

It is used for all bodies. Should it be relaxed for rats?...

It seems that TDM does not render on Terascale1 GPUs... I wonder if this is the problem with menu only or with all rendering? For instance, if you unpack the attached zip into TDM installation directory, and then start the game with command line parameters: TheDarkModx64.exe +map test/5598_crazyhedge.map UPDATE: After some time you need to click (attack) to start gameplay... Will it show anything when game starts? (if you are not sure you did everything right, you can look at game console: it will print a lot of stuff when you start a map, plus sounds will change too) maps.zip

Perhaps it would be a good idea to check the "Beta Testing 2.08" thread and try to change cvars listed there. For instance: r_uniformTransforms 0 r_fboColorBits 32 r_usePersistentMapping 0 r_useMultiDraw 0 and r_useBaseVertex 0 (I guess they don't exist in 2.09 anymore)

It says "This file is not public." to me.

At some moment in the future we will release 2.09b fixing that. As of now, either use the latest dev build, or edit darkmod.cfg: seta r_glCoreProfile "0"

Most likely we will release 2.09b hotfix fixing that in a few weeks.

I searched for spotlights in released FMs: Non-orthogonal T/R/U is used frequently. T not orthogonal to RxU plane is used frequently. S->E direction not collinear to T is used rarely. I have attached log files showing all problematic entities in each category, with sine/cosine of angle printed for them. Low numbers means that directions are almost collinear/orthogonal. So, we can supposedly leave arbitrary start/end case broken. In fact, I'd say it is better to forcibly project "start"/"end" onto "target" direction. The most important broken cases would be light_attic_yellow_window in bcd and light_7 in windowopportunity. As for near/far planes, @duzenko has already committed the change to return to old behavior: just use "end" - "start" instead of "end", which means that far clipping plane is now at "end" and falloff parameter = 1.0 at "end" too. But as for non-orthogonal T/R/U, I guess we'd better reproduce the old behavior. spotlights_TRU_nonortho.txt spotlights_RUplane_T_nonortho.txt spotlights_SE_T_noncollinear.txt

I reproduced the error on current SVN. The warnings are generated because world bounds are "(0,0,0) - (0,0,0)". Since most entities are far from origin, this warning is printed for them. It also explains the weird "memory effect" that you are seeing: proper bounding box was loaded during previous map start, but bounding box is not updated updated during current map start, so the bounding box from the previous start retains. It might be totally incorrect if two maps are unrelated, but in your case it stops the warning spam. I did not get to the root cause yet, but will do in the future. Most likely something about loading collision models got broken. I refactored/optimized something related to collision models loading in the latest dev build, and probably did not test it well enough to notice that I broke stuff real hard. Meanwhile, use previous dev build. Also, if someone else sees the same problem on the latest dev build, please report it here. I'm not yet sure if the problem happens always, or is specific to this map...

Your Windows says "tdm_installer is not responding", but it still refreshes itself occasionally --- that's OK. The reason is that tdm_installer is completely single-threaded, and it can only handle user input when it is not doing something useful. That's rather poor way of writing GUI applications, but I did it in order to avoid any kind of errors that multithreading can easily bring. Regarding errors: I can't say anything without knowing the exact error. In fact, the best way to diagnose installer errors is to attach tdm_installer_XXXXXXXX.log file. A new such file is created every time you start the installer. If you are not sure which of these files captures the problem, just zip and attach them all.

Regarding 2.09 vs 2.09a / hotfix: Did you install TDM using tdm_installer.exe ? You can see whether you have 2.09a or 2.09 by looking at .zipsync/lastinstall.ini: [Version] version=release209a Or you can find line seta logFile "0" in darkmod.cfg and change it to seta logFile "1", then find qconsole.log and attach it here. It should contain engine revision number, which can be used to understand which version it is. Anyway, your problem will most likely happen both in 2.09 and 2.09a. Regarding the black screen problem. Most likely it is the same issue @freyk linked above. Especially since you confirm that test15973-8787 works properly. The current workaround for this problem is to set following in darkmod.cfg: seta r_glCoreProfile "0" After that 2.09a should work fine. Also, this problem is fixed on the latest dev build. But dev build are not recommended for normal playing: better use release2.09a with core profile fix. Also, I think we will release another hotfix for 2.09 (that would be 2.09b) somewhere in November. Specifically to fix this particular problem, and maybe something else. Make sure to install this second hotfix when it is released.

No. We should differentiate between convention (is falloff in Z or W? should it be scaled by some number?) and behavior (shape of frustum, falloff value). Yes, the current code converts the matrix from BFG convention to D3 convention, but it does not & cannot convert behavior. And behaviors are different between D3 and BFG. If start/end vectors are not collinear with target vector, then you cannot convert D3 matrix in such a way that idRenderMatrix::ProjectedBounds/baseLightProject would work properly with the result. In BFG, light volume is always a frustum, but in D3 its near/far planes can be arbitrary. Maybe something can be hacked by making target vector non-orthogonal to R/U plane, but I'd better avoid that.

That would be incorrect, because BFG frustum and D3 frustum can be different geometrically. You suggest drawing D3 frustum but culling BFG frustum. In some rare cases light might disappear due to incorrect frontend culling.

I'm going to run analysis over all released FMs to see which atypical cases are present where. I hope we will be able to restrict R/U/T to orthogonal and start/end to being collinear with T, in which case the only difference would be falloff = 1 at far vs (far + near), which I guess we will be able to fix...

It is not so easy, because in both cases light frustum which is later used in frontend depends on the matrix row which defines falloff parameter. This code won't work properly with D3 light matrix: // calculate the global light bounds by inverse projecting the zero to one cube with the 'inverseBaseLightProject' idRenderMatrix::ProjectedBounds( light->globalLightBounds, light->inverseBaseLightProject, bounds_zeroOneCube, false ); Because it assumes that matrix is 3x3 projective transform, i.e. it relies on BFG definition with Z divided by W. Doom 3 code used to set clipping planes directly from start/end parameters, so the resulting polyhedron does not need to be frustum: /* =================== R_SetLightFrustum Creates plane equations from the light projection, positive sides face out of the light =================== */ void R_SetLightFrustum( const idPlane lightProject[4], idPlane frustum[6] ) { // we want the planes of s=0, s=q, t=0, and t=q frustum[0] = -lightProject[0]; frustum[1] = -lightProject[1]; frustum[2] = -(lightProject[2] - lightProject[0]); frustum[3] = -(lightProject[2] - lightProject[1]); // we want the planes of s=0 and s=1 for front and rear clipping planes frustum[4] = -lightProject[3]; frustum[5] = lightProject[3]; frustum[5][3] -= 1.0f; frustum[5][3] /= frustum[5].Normalize(); frustum[4][3] /= frustum[4].Normalize(); frustum[3][3] /= frustum[3].Normalize(); frustum[2][3] /= frustum[2].Normalize(); frustum[1][3] /= frustum[1].Normalize(); frustum[0][3] /= frustum[0].Normalize(); } In order to restore D3 code for shading but retain BFG code with inverseBaseLightProject, one has to: Build D3 matrix. Compute 6 planes from D3 matrix using D3 code. Build polytope from these planes. Bound polytope vertices from forward/backward, i.e. determine minimal near/far clipping distances which are enough to cover the whole light volume. Build BFG matrix with several adjustments: a) "target" is orthogonalized like in D3, b) near/far values taken from what we obtained on step 4, c) replace "far" with "far" - "near". Use D3 matrix for shading, and BFG matrix for culling.

Theoretically, "end" should map to falloff = 1 with D3 code and to (1 - f/n) with BFG code. Yes, it has changed its meaning, as well as handling of non-orthogonal "target" and weirdly-oriented "start"/"end". Given that behavior was silently changed to BFG several releases ago (I guess since 2.05), we have to decide which behavior should be left now so that number of broken FMs is minimal That's why I never understood why some people tried to copy/paste some bits of code from BFG without any reason for doing so, except "maybe it would be faster... ID did this, so it must be better" Yes, sort of. Now matrix is generated in BFG convention, but then converted to D3 convention. As long as people remember what happens where, it should be OK.

So, I think the current code is close to BFG, except that someone has changed zScale from 1/(n+f) to 1/f (which most likely does not achieve the desired effect). If we change it back to 1 / (n+f), then we'll have BFG behavior. Here are the differences between D3 and BFG: D3 falloff ends in W, BFG falloff ends in Z and is multiplied by (f+n). Minor postprocessing code converts the matrix from BFG convention to D3 convention. D3 falloff changes along "end" - "start" vector, which makes it completely independent of the frustum. BFG falloff always changes along the frustum's main direction. Both falloffs are 0 at "start", but D3 falloff = 1 at "end", while BFG falloff = 1 at "start" + "end". If "target" is not orthogonal to "right"/"up" plane, then D3 internally projects it onto plane normal and uses the projected vector instead of "target" everywhere. BFG does not care and uses "target" directly. What next? We have to decide which of the two behaviors we want to reproduce both in TDM and in DR? By the way, does DarkRadiant support D3BFG maps? UPDATE: I guess I can restore both functions and allow switching between them easily...