stgatilov

Which value of "Uncapped FPS" do you use? Does the problem happen with both values?

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?

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

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?

These are errors in compiling WIP volumetric light error. @duzenko might be interested in seeing them, but this shader is only used if you use "volumetric" material keyword, and it only affects graphics: shaders never affect gameplay. So, it is completely unrelated to your problem.

According to the code, the warning means that the bounds of an entity and the bounds of the whole world's collision map (expanded by 128 units) are disjoint, which means that entity is outside playable area (dropped down into abyss, or got through wall). No idea why it happens for you.

@Bridge, could you try this curl command? curl http://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip -A "tdm_installer/1.09" -o out0.bin It should download whole file instead of byterange, maybe your network does not support byteranges for some reason...

I suppose this is 2.09 original release. Is there 2.09a hotfix on moddb?

I confirm that it downloads config file successfully, but fails to download installer zip and versions manifests. Why it allows to download a small text file, but fails on zip file? The interesting thing is that it fails the same way for all the 5 mirrors we have. So this is surely not a problem of our mirrors. Note that we don't have any central dispatcher or similar stuff: the problem is either in the installer, or your machine, or something on the network from you to the internet. I think the installer can be ruled out All the files are directly downloadable in the browser or with curl command. In fact, you can try to reproduce the error with standalone curl tool, just try to execute strings prefixes with [curl-cmd] in the log, e.g.: curl http://update.thedarkmod.com/zipsync/tdm_installer.linux64.zip -r 0-127 -Y 1000 -y 10 --connect-timeout 10 -A "tdm_installer/1.09" -o out0.bin curl http://mirror.mstrmnds.me/releases/zipsync/release/release203_from_release202/manifest.iniz -r 0-127 -Y 1000 -y 10 --connect-timeout 10 -A "tdm_installer/1.09" -o out5.bin If it fails with independent curl tool, then it's not the installer to blame. Most likely it is a problem on your end. I don't believe all 5 mirrors are misbehaving at once, and you can reproduce the problem without using installer (i.e. with browser). Could it be some kind of firewall/antivirus blocking binary or large files but allowing text or small files to pass? Meanwhile, you can try to download 2.09a with attached torrent, although the torrent file points to the same HTTP mirrors (aka web seeds) and is not tracked. It is quite likely that your torrent client won't work for the same reason. release209a.torrent

I need to do the same analysis for the old matrix, then see what is different between the old and the current one.

NOTE: This analysis assumes W as perspective divisor, which is wrong!

Wow! I think idStudio from Rage deserves its own discussion. I was always wondering whether e.g they still use brushes today... But if we start discussing it here, the thread will be hopelessly stolen

But if we find that D3 math related to such light frustums makes no sense, then what? Where is it located, by the way?

Do you think skewed/asymmetric frustums are important? I think you can always replace it with orthogonal/symmetric frustum without much problem...

In the recent TDM, any dropped portal should result in some kind of warning during dmap. Find this warning, and if a .lin file is generated, inspect it in DarkRadiant. Most likely it will solve your problem.

Yeah, it is natural to assume (target, up, right) is orthogonal basis, like axes of coordinate system. Somehow, it reminds me the story of rotation hack: everyone assumed orthogonality but nobody restricted it. I wonder what would happen if we orthogonalize (target, up, right) spawnargs with Gram-Schmidt in game engine when parsing light spawnargs. How much stuff would stop working?

I think you exactly described the difference. Looking at D3BFG source, we see: The idea of swapping Z and W is merely a convention. Everyone in computer graphics uses W as divisor, so using Z instead is going to confuse people every time they have to deal with it. Of course, both ways work as long as every piece of code (including shaders) where it is used knows which coordinate to divide by. Given that D3BFG added a bunch of matrix-related code in SIMD, I suppose they had issues with maintaining the old convention. As for scaling of the last column, I think it is also merely a convention. The only difference would be scaled Z value (in standard terms, i.e. Z is non-divisor coordinate) after transformation. It means displacement along light rays, and I'm not sure anything in the original Doom 3 depended on it. Once again: you can work equally well with any of these conventions, as long as you understand what Z (non-divisor) means when you have to use it. Moreover, you can always pass (far+near) coeff as separate uniform into shader to get the same behavior regardless of what is written in the matrix, although that would look stupid. I'd say the better convention is where Z coordinate (non-divisor) is always in same [0..1] range regardless of the far/near clipping distances. Somehow, it seems to be D3BFG matrix, but better check it. Most likely because the code which build corners in each case knows the conventions it works with So, the bottom line is: both matrices are the same thing as long as you apply them according to the conventions they have in mind. D3BFG conventions seem to be more standard and convenient.

By the way, I have already implemented texture decompression locally, which makes image programs work on DDS files. As soon as I commit it to SVN, the issue on Saint Lucia will return.

spawn atdm:moveable_flask1 Highlighting with plain white will make things look milky. Highlighting with diffuse texture does not work for some specular objects. There is no universal rule to highlight everything, I'm afraid.

Well... any outline will make mesh geometry more visible. As for partly visible pixels: that's the price for respecting depth, I'm afraid.

The main plan is to remove frob-highlight stages from materials. It seems that it is not possible to implement a universal rule for highlighting all objects. The current rule works fine in 99% cases, but there are some objects which don't react. The outline is here to help with these cases. So... please stop saying "just disable outline!", don't ignore the problem.

This is (or soon will be) not an option, if you want to avoid the issue when an item is frobable but does not highlight at all.

Wow, sparklies! Yes, bloom is applied after outline, and most likely it will remain so. You can set "r_frobOutlineColorA 2" instead of "r_frobOutlineColorA 5": the outline will still look hard, but I don't get these uberlights on highest bloom settings. It can be fixed properly of course, allowing to reduce r_frobOutlineColorA down to 1, but that would need code fix.

It seems frob outline does not work in old backend right now.

The latest build dev16368-9627 contains a lot of changes in how frob outline/highlight works. Moreover, the outline is enabled by default again... but not the same one as before. Now there are two different implementations of frob outline: Image-based outline is the old one (r_frobOutline 1) --- was default previously. Geometric outline is the new one (r_frobOutline 2) --- currently set as default. Note that the image-based outline works a bit differently than before: there were fixes for alpha-tested surfaces, depth fighting issues, translucent objects. Both of the implementations have some strong and weak points, and it's not clear yet which one suits TDM better. Cons of image-based outline: Outline has to be thick. Some visual artefacts due to depth test conflicts. Cons of geometric outline: It does not fully support alpha-tested surfaces. Soft version has intensity bumps at mesh vertices. To simplify testing, there are three presets which can be enabled easily: r_frobOutlinePreset 1: hard geometric outline (set as default for now) r_frobOutlinePreset 2: soft geometric outline r_frobOutlinePreset 3: image-based outline Here r_frobOutlinePreset is just a command, which sets a bunch of cvars to proper values. All three presets respect depth. The old frob-related cvars should still work as they did, in case you want some fine-tuning. You can also change thickness of geometric outline via cvar r_frobOutlineExtrusion.