Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
 View Profile  See their activity

  • Content Count

    7988

  • Joined

  • Last visited

  • Days Won

    35

 Content Type 

Everything posted by OrbWeaver

  1. OrbWeaver
    I will see if the issue reproduces on my machine (currently Ubuntu 20.04, I only use LTS releases on my main machine). It looks like the sort of problem that can probably be solved by adding some extra "refresh window" call in a suitable location, even if it isn't entirely obvious why the existing code doesn't work. I seem to remember encountering a similar issue when hiding/showing the 3D camera view toolbar (you'd have to resize the widget before it would actually disappear).
  2. OrbWeaver
    We do have an option called something like r_showSounds, which shows playing sounds and their locations and I think (but could be misremembering) this also includes the current ambient sound. But perhaps it only shows ambient sounds that are associated with specific speaker locations rather than background music.
  3. OrbWeaver
    Thanks for the pointer, I'll see if the associated commits fix the problem on my machine.
  4. OrbWeaver
    I'm happy to push the 2.9.1 version into my PPA. As Greebo says, we don't have direct control over the version that goes into Debian proper, that's up to their own maintainer(s).
  5. OrbWeaver
    infirmity, decrepitude, senility and dotage seem to be the most common suggested translations from "Altersschwäche", although interestingly none of them seem to be an exact match. infirmity means sickness or weakness, but doesn't include the meaning of "old". Old people are often infirm (and often described as "old and infirm") but you can also be infirm without being old. decrepitude is probably the closest match, with a meaning of "decay due to old age", although I've most often heard it applied to buildings and objects rather than people. I think calling an old person "decrepit" w
  6. OrbWeaver
    Having just upgraded to Ubuntu 20.04, I can now reproduce this problem. As of Git 6a093c45fad6bb69ed4ccd8e76df121313917cfc, I am now explicitly requesting python3-config instead of the unversioned and deprecated python-config, which fixes the compilation error but does not fix the loading of the script module due to the missing _Py_ZeroStruct symbol.
  7. OrbWeaver
    I think your numbers are slightly out of date. I haven't seen any scientist seriously suggest a mortality rate that high since about February or March. Even the infamous "Ferguson model" used to justify lockdown in the UK assumed an overall mortality rate of 0.9%, and most estimates since then have been somewhere between 0.3% and 0.6%. Maybe if you only look at hospitalised cases you can get a fatality rate of 2-5%, but that's not equivalent to the fatality rate for the whole disease. What is the source for the claim that 40% of cases will develop long covid? Don't worry,
  8. OrbWeaver
    Yeah, they're complete idiots. Everybody knows that the only safe forms of protest are Black Lives Matter or Extinction Rebellion. The super-intelligent Covid virus knows who the goodies and the baddies are, and specifically avoids infecting anybody on the left of the political spectrum. This is why BLM and XR rallies are perfectly safe and actively encouraged by the state, whereas anti-lockdown protests are dangerous super-spreader events which result in £10,000 legal fines.
  9. OrbWeaver
    Makefiles are not package managers. I guess the developers of Autotools added a "make uninstall" target for convenience (so you can uninstall the existing build, then run "make install" to install the latest build), but this behaviour is not within our control and not something we are likely to spend time trying to support. With regard to the ~/.config/darkradiant and ~/.cache/darkradiant directories it would be inappropriate and impractical for an installer to touch these, since they are user-specific directories not system-wide installation directories. Users are unlikely to want to tra
  10. OrbWeaver
    I tested this in Linux with the released version and it works! If you are holding down the arrow key to move forward and you click the right mouse button, the speed suddenly increases. But I think it might just be an accident. Perhaps using a mouse button does something to the event processing which means that the arrow key motion events are suddenly processed faster?
  11. OrbWeaver
    One option would be to move to something more like what Blender does, where the overall config directory is divided into version-specific subfolders which contain settings for each version. So DR version 2.08 would store its settings in $HOME/.config/darkradiant/2.08 (or Windows equivalent), then the next version in $HOME/.config/darkradiant/2.09 etc. This would mean some additional code required to handle upgrades (i.e. if there isn't a 2.09 subdirectory, create it, then copy the existing settings from the highest existing version directory), but ought to completely solve the problem wit
  12. OrbWeaver
    You mean the button "Cubic clip the camera view" on the main horizontal toolbar (4th from the left, next to "Change views")? I had no idea that button even existed. In my tests the button does toggle, but all it seems to do is enable/disable the clip plane buttons in the camera view (which move the far clip plane closer or further away). The clipping still happens, which makes some sense because as I understand it, it's not actually possible to render without both near and far clip planes. I wonder how this button was supposed to work — does "disabling" clipping just move the far clip pla
  13. OrbWeaver
    That part is fine — I understand the bits of code which subtract the origin, handle the rotation key, scale the light radius into a [-0.5, 0.5] box (for omni lights) etc. But with projection it's a whole new ball game, because we have three distinct vectors (which are not necessarily orthogonal), both a Z and a W coordinate which must vary along the target vector (but with different ranges), and the target vector can also be "sheared" sideways and affect the X and Y coordinates as well. I think the mistake the current DR code makes is to try to map the projected volume into an AABB (befor
  14. OrbWeaver
    Thanks for the suggestion, but it doesn't really help: that is a very different way of implementing a spotlight, which is conical in shape and implemented entirely with math in the shader, whereas our spotlights are squar(-ish) pyramids defined by three vectors and implemented by using a matrix to map two falloff textures. The problem is that while I understand the general idea and parts of the mathematical process, it all seems to fall apart when I get down to the nuts and bolts and look at the matrix and vectors themselves. I won't abandon this work entirely but maybe poke at it from ti
  15. OrbWeaver
    Do you have a CONFIG_SITE environment variable set? As far as I can see from the documentation, this is the only way that DarkRadiant's configure script should be reading the contents of /usr/share/site/x86_64-unknown-linux-gnu or any other site-specific script.
  16. OrbWeaver
    Nope, this is beyond me. Even after trying to incorporate the D3 code into DR, all I have achieved is swapping one set of meaningless numbers for another. I could stare at this code for the next 20 years and still have no idea what it's even trying to do, much less how to fix it. Projected lights don't work correctly in DR, and they probably never have. I guess most people don't fiddle with light_target vectors very much anyway, but if they do, perhaps stgatilov's "live update" code will allow them to check the result in game without needing to bother with the DR renderer.
  17. OrbWeaver
    Forgive the possibly obvious question, but did you make sure to clear the install path before building and installing DarkRadiant, to ensure there aren't any stale libraries or modules? None of this really makes sense, to be honest. As Greebo correctly points out, the DarkRadiant build scripts are not supposed to require or create a lib64 directory, and the use of relative paths (e.g. install/bin/../lib/darkradiant/modules/sound.so) should only happen if you enable the "relocatable build" configure option which is disabled by default. What happens if you try a fresh, clean checkout i
  18. OrbWeaver
    Sorry I don't quite get what you mean. As I understand it, a matrix can never actually clamp anything, because that would be a non-linear transformation. The purpose of the matrix is to transform the coordinate system so that the volume, which (as you rightly say) is specified in world coordinates like [128, 128, 64], ends up with texture coordinates like [0, 0, 0.5] or [1, 1, 1]. Coordinates outside the light volume would still be transformed in this way, but they would end up with texture coordinates above 1 or less than 0, which would then be clamped to black by the OpenGL edge clampin
  19. OrbWeaver
    I think the approach I will take is to assume the D3 code is correct, and try to adapt it as best as possible to fit DR, if changes are needed. So as stgatilov helpfully pointed out, the relevant code is in R_ComputeSpotLightProjectionMatrix(). The first code block is easy to understand, although written in a slightly weird way. I wonder if this is an optimisation because calculating "inverse square root" is quicker than calculating the regular Pythagorean length using square root. const float targetDistSqr = light->parms.target.LengthSqr(); const float invTargetDist = idMath::InvS
  20. OrbWeaver
    I think that's implied though, isn't it? We have (with added W coordinates): So the Z coordinate must go from 0.5 at the origin to either 0 or 1 at the target point (either should look the same because the Z falloff texture is symmetrical, but I guess DR should do the same as what the game does). It is definitely going to need an offset of 0.5, resulting in a formula like: Z[tex] = 0.5 + 0.5 * (p · t̂) / ‖t‖ where t̂ is the normalised target vector and p is an arbitrary point within the volume whose Z texture coordinate we want to calculate.
  21. OrbWeaver
    Modelling with that level of detail is not really possible within DarkRadiant, but could be achieved quite easily in Blender, perhaps using sculpting or texture painting. I presume it can also be done just as easily in other 3D applications like LightWave, Maya etc, although I have no personal experience with these. It sounds like you are looking for a custom skybox.
  22. OrbWeaver
    Do you have the required darkmod.txt and startingmap.txt configuration files in your fms/mymission directory?
  23. OrbWeaver
    Actually I think I'm wrong about this one. It's not the texture coordinates which are 0 at the origin, it's the image size. The texture coordinates are therefore effectively infinite, but this will not be achieved by actually setting the X and Y coordinates to infinity, but by setting the projective (W) texture coordinate to 0, causing the projective texture lookup (X/W, Y/W) to blow up to infinity. I think this means that the W coordinate will vary from 0 at the light origin to 1 at the light_target plane. In any case the next step will be to add some suitable debugging code to prin
  24. OrbWeaver
    OK, let's start from the beginning (this will be a useful intellectual exercise and perhaps create some useful documentation that might help future development. A projected light works by mapping points in 3D space into texture coordinates, which are then used to sample a 2D light falloff texture and a separate 1D gradient texture resulting in a final color for each illuminated pixel. Every point within the light volume should be transformed into a triplet of texture coordinates, where the X and Y coordinates (conventionally called S and T in a shader) run from 0.0 to 1.0, and the Z coord
  25. OrbWeaver
    That is actually very helpful, thanks. I just did a test, and rotating the light using the rotation tool works fine, including the render preview. The rotation is not applied to the target vector, but stored in a separate rotation spawnarg which is applied to the texture matrix in a separate step, and this appears to be working fine. This would explain why mappers might not have noticed the problem: since you can change the shape of the light OK, and change its direction by rotating, manual dragging of the light_target vector may be unnecessary. In summary: The location of th
×
×
  • Create New...