Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
 View Profile  See their activity

  • Content Count

    8042

  • Joined

  • Last visited

  • Days Won

    35

 Content Type 

Everything posted by OrbWeaver

  1. 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
  2. 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
  3. 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.
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. OrbWeaver
    Do you have the required darkmod.txt and startingmap.txt configuration files in your fms/mymission directory?
  11. 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
  12. 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
  13. 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
  14. OrbWeaver
    I played for a while, but eventually gave up because with every single guard helmeted this began to feel like a "forced ghost" (no knockouts) mission which is a style I don't personally enjoy. I won't rule out coming back to it at some point however, if I feel like a challenge. Feedback based on what I did see: While it was thrilling to hear somebody actually use my ambient music, I did wonder if you perhaps used too many different ambients. With a different one in almost every room there was a bit of "mood whiplash". I'd probably tone down the variety a little: maybe one ambient
  15. OrbWeaver
    Thanks for all the support and offers of help; I didn't realise this would get such a positive response. I will post my investigations in this thread (partly for my own sanity, partly for future documentation in case this needs to be debugged again, and partly so anyone can jump in in case I'm going completely off the rails). I'm sure there will be some differences in the matrix DR needs, but this will still be helpful as an aid to understanding the process, so thanks for the pointer.
  16. OrbWeaver
    While doing some render system refactoring I noticed that projected lights were not rendering correctly in lighting preview mode, and thought it was something I had broken until I regressed to earlier revisions and discovered that it has actually been broken for some time (in fact I tried checking out revisions from 3 years ago and the problem still reproduced). Projected lights are something of a "bug trap" because I think most mappers don't use them or the DR lighting preview very much and therefore they don't get a lot of testing. The behaviour I see is that while the rendered light pr
  17. OrbWeaver
    If you bring down the console with Ctrl + Alt + <key above TAB> the game will release the pointer, although this does also mean that the console will now be obscuring half of the window.
  18. OrbWeaver
    That doesn't surprise me all that much — I have a feeling that brace initialisation is actually more strict than normal construction and won't allow certain implicit conversions of parameter types. Using static_cast seems like the ideal solution here in any case, since casting one type to another is indeed what the code is doing.
  19. OrbWeaver
    No problem. The attached patch fixes all Linux compilation issues that I encountered. I wasn't sure what to do about this line in PassiveSocket.cpp: SOCKET socket = UINT_PTR(CSimpleSocket::SocketError); UINT_PTR isn't defined anywhere, so I assume it must be a Windows-specific type, but CSocketError is just an enum not a pointer, so I'm not sure of the intent here. Does it work on Windows because SOCKET and UINT_PTR are both typedefs of the same type (e.g. unsigned int*)? The original clsocket code looks very odd: I'm not sure why the author used the SOCKET variable to
  20. OrbWeaver
    Sorry, that was probably my fault. Sometimes when I encounter misalignment due to mixed tabs/spaces on successive lines, I use Vim's :retab command but forget to select just the affected method body, which results in Vim converting tabs to spaces in the entire file.
  21. OrbWeaver
    I've read that in real-world security, patrol randomisation is actually important for precisely the same reason that it makes gameplay more difficult — if an attacker knows that a guard walks around the perimeter every 30 minutes, he has 29 minutes of complete security to cut the fence without any risk of being detected. This might apply more to timings rather than paths though. Humans are notoriously bad at choosing things "randomly", and you certainly wouldn't want a situation where guards neglected a particular area for hours because it was never randomly chosen, or all ended up coveri
  22. OrbWeaver
    No problem — I'm not trying to pressure you into merging it right away, just getting the code into a reasonable state so that when you do get time to merge it there shouldn't be too many obstacles.
  23. OrbWeaver
    I've moved the game connection code into its own plugin, which is now built when --enable-darkmod-plugins is set (on Linux). This was more work than I originally anticipated since I had to move quite a few classes from the radiant/map tree into libs/scene instead, so they could be used both by the plugin and the main Radiant module. I also had to expose certain methods on pure virtual interfaces which were previously only defined in implementing subclasses, which was relatively straightforward. Hopefully I've done all the necessary legwork at the code level, so that when @greebo eventuall
  24. OrbWeaver
    Good God, it's like reading a bunch of 90s Microsoft executives discussing open-source in this thread. Open-source developers are idiots giving away valuable IP for free, open source is communist, open source licenses are viral and take ownership of your own code, open sourced code is abandonware which will wither and die, open source will put commercial developers out of business, yada yada. That this is the development forum for an open source game makes it even more bizarre. Neither ZLib nor PNG are GPL licensed, so that's flat-out misinformation. I suppose companies might be doing
  25. OrbWeaver
    Right, that would make sense. Normally what I do is bring down the console in order to switch to another application, because otherwise the game window continues to capture the mouse and I cannot click anywhere outside the game (which is not ideal in this situation, because now the console is obscuring half the window and I can't see the live updates). I must have tried Alt+Tab without bringing down the console and that is what entered the strafe mode.
×
×
  • Create New...