Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


stgatilov last won the day on October 20

stgatilov had the most liked content!


1643 Deity

Contact Methods

  • Website URL
  • Jabber

Profile Information

  • Gender
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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...
  5. 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.
  6. 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.
  7. 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...
  8. Ok, here is corrected analysis for BFG code, assuming that falloff parameter is not divided by W. See all the formulas in PDF. Some notes: The inputs are the same as usual: R, U, T are unit vectors from spawnargs, and W, H, D (aka width, height, and depth) are the lengths of spawnargs. Coordinate "w" is divisor for "x" and "y", but not for "z". You can see decomposition of matrix into three transforms, which produce homogeneous coordinates for "x" and "y" in range [0..1] both. Computation of the falloff coordinate "w" is totally independent of this transformation. Coordinate "z" (falloff) must be scaled down by (n+f), which is achieved by returning 1 / (n+f) from R_ComputeSpotLightProjectionMatrix, then multiplying matrix[2] row by it. "start"/"end" spawnargs define linear gradient of falloff parameter, but only their component along "target" vector matters, the two other components don't affect anything. Let n = dot(target, start), f = dot(target, end). Falloff = 0 is at distance n, and falloff = 1 at distance (f + n). Quite surprisingly, "end" vector does not define the end of falloff texture, but ("start" + "end") does. Frustum half-angles are: length(right) / length(target) and length(up) / length(target). Multiplying all three vectors by same coefficient does not change anything, only their length ratios matter. If R/U/T triple is not orthogonal, then the matrix which I called "rotation" is no longer orthogonal. Strictly speaking, it maps a parallelepiped with face normals R, U, T respectively into axis-aligned box. The vectors are not axes of the local coordinate system (I guess they are called "cobasis"), they are not normals of frustum planes. Judging from point 8, I don't think non-orthogonal R/U/T were ever intended. However, if there is no special tools, drawing/specifying three exactly orthogonal vectors is very hard. If mapper sets almost orthogonal vectors, then the transformation will work almost as if they were orthogonal... I'd say the spawnargs should be set as follows: Set frustum direction into "target" vector, choose length arbitrarily. Specify X/Y coordinates on frustum "screen" by choosing orthogonal "right" and "up" vectors. Set lengths of "right" and "up" in such way that (target +/- up +/- right) vectors look through frustum corners. Choose "start" and "end" so that falloff is zero at "start", and unit at "start" + "end". DeriveLightData_Spot_BFG_v2.pdf
  9. BFG interaction shader: /*vertex*/ //# texture 2 has one texgen result.texcoord2 = defaultTexCoord; result.texcoord2.x = dot4( vertex.position, rpLightFalloffS ); //# texture 3 has three texgens result.texcoord3.x = dot4( vertex.position, rpLightProjectionS ); result.texcoord3.y = dot4( vertex.position, rpLightProjectionT ); result.texcoord3.z = 0.0f; result.texcoord3.w = dot4( vertex.position, rpLightProjectionQ ); /*fragment*/ half4 lightFalloff = idtex2Dproj( samp1, fragment.texcoord2 ); half4 lightProj = idtex2Dproj( samp2, fragment.texcoord3 ); Looks the same as in Doom 3: falloff parameter is not divided by perspective divisor of light matrix. By the way, it is divided by perspective divisor of vertex position, which is necessary to correctly support vertices with w != 1.0. I guess we don't have such values (except for shadows), so it does not matter. It means that my analysis for BFG is wrong: the depth is linear there too. I'll edit that post in the nearest future. P.S. I suppose they use the same light matrix with perspective division in the other parts of BFG code, which could be the reason why they decided to change conventions. The BFG matrix yields 0 at near and 1 at (near + far) both with and without division (given that someone has scaled the matrix by far+near) and results are monotonous. It can be used as ordinary MVP matrix e.g. for shadow maps of a spotlight... which would be a good explanation if D3BFG had shadow maps
  10. So... does anyone have D3 BFG installed? I need only glprogs to understand what happens there...
  11. Can the problem be reproduced on released FM? Can I somehow get a local copy of your FM for debugging?
  12. Which value of "Uncapped FPS" do you use? Does the problem happen with both values?
  13. Looking at tdm_interaction.*.glsl, I see: // (VS) light projection texgen var_TexLight = ( attr_Position * u_lightProjectionFalloff ).xywz; // (FS: lightColor) vec3 lightProjection = textureProj(u_lightProjectionTexture, var_TexLight.xyw).rgb; vec3 lightFalloff = texture(u_lightFalloffTexture, vec2(var_TexLight.z, 0.5)).rgb; lightColor = lightProjection * lightFalloff; I guess these equations come from D3 shaders, and probably confirm my theory that W parameter is not divided by perspective divisor in D3. It would be great if someone could find the original shader from Doom 3 and check it. However, I have some doubts now about BFG: perhaps Z is not divided by W there too. Could someone please check it?
  14. Ok, here is the analysis of the old R_SetLightProject code before @anonreclaimer 's commit broke it in rev 6684. Some notes: The inputs are the same as in the previous analysis: R, U, T are unit vectors from spawnargs, and W, H, D (aka width, height, and depth) are the lengths of spawnargs. It looks like "z" is the perspective divisor here, but it is applied only to "x" and "y". The falloff coordinate "w" should not undergo perspective division. You can see decomposition of matrix into three transforms, which produce homogeneous coordinates for "x" and "y" in range [0..1] both. Computation of the falloff coordinate "w" is totally independent of this transformation. Falloff parameter at a point is determined by its projection to "start"-"end" line segment: it is 0 at start, 1 at end, 0.5 in the middle, etc. In fact, falloff parameter changes linearly from 0 to 1 while going from S to E. Note that it does not depend on the frustum at all: you can e.g. have frustum direction and falloff direction different. Frustum half-angles are same as in BFG case: length(right) / length(target) and length(up) / length(target). If R/U/T triple is not orthogonal, then things go equally uncertain as in BFG case. Except that here T is made orthogonal to R/U plane, and becomes N. At the same time, size D is adjusted too: we take length of "target"'s projection along N instead of full length of "target". This perhaps gives some sense to the whole stuff when R and U are orthogonal but T is not. According to p.6, this code supports T not being orthogonal to R/U plane in some sense. In fact, only the component of "target" orthogonal to R/U plane matters, the component along R/U plane is dropped away. Note that you cannot create a non-orthogonal light frustum, so this "support" does not offer any additional flexibility. The case of non-orthogonal R and U still looks like unsupported/unintended. Here is how this light can be set up: Specify X/Y coordinates on frustum "screen" by choosing orthogonal "right" and "up" vectors. Specify direction of light frustum by setting "target" vector. Only the orientation (which side of the plane "target" looks into) matters. If you set non-orthogonal "target", then it is automatically replaced by its projection onto X/Y plane normal in the engine. Set lengths of "right" and "up" in such way that (target +/- up +/- right) vectors look through frustum corners. Here "target" is the orthogonal vector already "fixed" by the engine if you set it non-orthogonal. Choose "start" and "end" points completely independent of all the previous parameters. Falloff parameter ranges from 0.0 to 1.0 as you move point from "start" to "end". Gradient of "falloff" parameter goes along "end" - "start" everywhere. DeriveLightData_Spot_D3.pdf
  15. You can check if the map works properly on TDM 2.09. If it does, then bisect over dev builds of 2.10 and see which dev builds is the first non-working. After that we can looked at changelog and maybe we'll guess what is the problem. Although I think at least some understanding about how it happens would be welcome. By the way, when player1 is said to be outside world, where are you located? Are you somewhere in the void, or are you still standing at starting spawn location?
  • Create New...