OrbWeaver

I looked at this a couple of weeks ago because I was confused about the interaction with image_use[Normal]Compression and precompressed textures. It turns out that if image_usePrecompressedTextures is on (which it must be otherwise the mod will have mostly black textures), the precompressed images are used automatically and exclusively (if present), and the values of image_use[Normal]Compression have no effect whatsoever. The latter cvars only affect what happens to uncompressed textures: are they compressed on the fly or used as-is? That should certainly simplify things. The shader won't care whether the original image was compressed or not, since all it receives is RG colour information regardless of the source format. Correct, that matches my interpretation of the code flow. Right, so they is some very slight inefficiency in recalculating the B channel where it might not strictly be necessary, but this is probably negligible on modern hardware and provides the massive advantage of not needing to change the shader behaviour based on the particular normal map source format.

I can see that causing problems from a user perspective. Users won't remember/know that they have to manually start the listener, but will just expect it to work and will be confused when entity updates don't get synchronised. So anything that can be done to make it work with minimal initial setup will be ideal. Your suggestion of starting it automatically when you spawn the game from DR makes sense. I would go further and start the entity monitoring automatically as soon as the connection was established (regardless of how the game was launched), even if the user just clicked the camera sync button. We can reasonably assume that once the user activates some synchronisation feature, they are probably going to want to use others. This means that the user doesn't have to pay the performance cost of having the listener always active if they never use game connection, but they also don't have to manually activate it.

I think that GUI suffers from the problem that several of the early mockups had: far too many widgets for the number of actual, useful options. The mockup I eventually came up with required only one button and one checkbox for each feature (basically "Do now" as a button and "Do always" as a checkbox). I couldn't identify any particular subfeature which required more than two widgets. I don't claim that my mockup is perfect but it does boil the options down the minimal set and might be helpful as a guide to layout. Having separate On and Off radio buttons is very non-standard, and it's not clear how the radio buttons would interact with the button (Do you need to set radio button to On or Manual before clicking the "Do Now" button, or does it just work? I'd vote for it just working, in which case the Manual option is redundant and the On/Off buttons can be replaced by a single checkbox or toggle button). Colour-changing radio buttons — ugh, please no. This isn't GarrettLoader and we don't use colour-changing dialog widgets anywhere else (unless they are specifically there to indicate colour, e.g. colour buttons in the Light Inspector and Themes editor). Button images are normally 16x16 and I create them in Inkscape, but of course you can use whatever you want. Drawing an image which is still readable at such a small size can be challenging; in general you need to stick to large, flat colours and make full use of the entire space (don't leave a 1-pixel internal margin).

Sure, I'm happy to commit it. One thing I didn't confirm however is whether the shader can correctly identify which normal maps need Z component reconstruction and which don't. If there are a mixture of precompressed RGTC files and uncompressed TGA or PNG normal maps, the shader presumably needs to know which are which (or does it just always reconstruct the Z component, regardless of whether Z information is present in the input image?)

No, I just put them into the dds tree and created a material for them, i.e. textures/orbweaver/tiles/rounded_slate { diffusemap textures/orbweaver/tiles/rectblocks_d bumpmap textures/orbweaver/tiles/rectblocks_local } But it turns out I was wrong about the normal map working. I just hadn't deleted the PNG original from the textures directory, and this seemed to be used instead. With just the DDS normal map present, I get missing/flat normals. However, I can get it to work with the following source patch: Index: renderer/Image_load.cpp =================================================================== --- renderer/Image_load.cpp (revision 9519) +++ renderer/Image_load.cpp (working copy) @@ -28,7 +28,7 @@ PROBLEM: compressed textures may break the zero clamp rule! */ static bool FormatIsDXT( int internalFormat ) { - if ( internalFormat < GL_COMPRESSED_RGB_S3TC_DXT1_EXT || internalFormat > GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT ) { + if ( internalFormat < GL_COMPRESSED_RGB_S3TC_DXT1_EXT || internalFormat > GL_COMPRESSED_RG_RGTC2 ) { return false; } return true; @@ -1145,7 +1145,7 @@ internalFormat = GL_COMPRESSED_LUMINANCE_LATC1_EXT; break; case DDS_MAKEFOURCC( 'A', 'T', 'I', '2' ): - internalFormat = GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT; + internalFormat = GL_COMPRESSED_RG_RGTC2; break; default: common->Warning( "Invalid compressed internal format: %s", imgName.c_str() ); The logic in FormatIsDXT() seems very fragile to me (making assumptions about the numeric values of all supported compression formats), but with this change I am seeing the expected normal maps with the ATI2 local image.

I think the only precompressed asset so far is the test texture on my hard disk (which I uploaded a few posts ago). It appears I was jumping the gun and assuming that this was already supported and maybe even used by the main mod, whereas it hasn't yet been implemented for on-disk DDS files. This was referring to the shaders in DarkRadiant, which don't yet support reconstructing the Z component from RG textures. But I only need to worry about this once there are precompressed textures involved, since DarkRadiant doesn't do any on-the-fly compression at all.

Thanks, that's useful. Now I'm even more confused, because it did seem to work (with precompressed DDS) last night, but didn't when I tried it last week, and it sounds like not working is actually the "correct" behaviour based on the code... I wonder if it's a graphics driver quirk or something. Maybe it happens to work occasionally but isn't working reliably due to mismatched formats. Right, hopefully I can take that calculation more or less verbatim from the TDM shader code. But I might hold off on implementing this for now; if the game doesn't yet support precompressed RGTC and nobody is using them, it is not so critical if DR can't correctly preview these normal maps.

Turns out it's not quite as simple as I hoped. RGTC isn't just another RGB format which can be sent to the existing renderer as-is, it's a two-channel normal map which needs the blue channel to be reconstructed by the shader. But first, I have to be sure I'm actually loading it correctly. @duzenko I'm a little confused by the game code (which I'm hoping to use as a guide). In idImage::SelectInternalFormat(), there is a check for image_useNormalCompression which then results in the image being compressed into GL_COMPRESSED_RG_RGTC2 format: // catch normal maps first if ( minimumDepth == TD_BUMP ) { if ( allowCompress && globalImages->image_useNormalCompression.GetBool() ) { return GL_COMPRESSED_RG_RGTC2; } return GL_RG8; } But in idImage::UploadPrecompressedImage(), a different format is chosen if "ATI2" is the FOURCC: case DDS_MAKEFOURCC( 'A', 'T', 'I', '2' ): internalFormat = GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT; break; So I'm not quite sure which is the right OpenGL format to use. Surely the chosen format should be the same regardless of whether a precompressed image is loaded or if the image is dynamically compressed at runtime? Or are these two GL formats actually identical?

Well I found the downside to BC5 compression: DarkRadiant doesn't currently support it. On the plus side, this does at least confirm that I exported the image in the correct format (it complains that "ATI2" format is not recognised). https://bugs.thedarkmod.com/view.php?id=5686 Hopefully it is very easy to fix, since we just need to pass the compressed data through in the correct OpenGL format.

Starting TDM from DR would actually be useful I think. If you could hit a single button which would start the game, enable automation, compile and launch the current map, move the player position to the current camera position... this would really cut down all of the manual switching between applications, entering "testmap" etc. In this case players wouldn't need to worry about the automation feature, entering console commands and the like. The automation would just be there under the hood to streamline the process.

That wiki entry reads more like a technical white paper than a feature documentation; I certainly wouldn't expect ordinary users to plough through all of that. It's probably about time DarkRadiant's own online documentation contained some instructions for using the game connection feature. I hadn't added it up until now because the feature was somewhat experimental and in flux, but now that it's been in the software for a few months and has visible UI elements associated, it should be documented. Of course we all know that users hardly ever read documentation, so improving discoverability of the feature is still important even if it is also covered by the user guide.

If people aren't using the feature, it is most likely due to a lack of discoverability — users don't know that the feature exists, or what benefit it can provide for them. This is probably not going to be fixed by tweaking the GUI layout or having more/fewer buttons, but there are some things which could be done to improve discoverability: Have the connection always active when the game is running, rather than having to go into the console and enable com_automation. Currently there is no way for users to even know that they have to do this without visiting the forum and reading the appropriate thread. If a user clicks on one of the camera-toolbar buttons, they will just get an error dialog and probably conclude that the feature is broken or useless. DR could dynamically detect when the game is running and automation is enabled, and automatically enable the respective buttons, rather than having them active (but not useful) at all times. This would be a clear change of state when automation was possible, which would encourage users to click on the now-active buttons to see what they did, thereby discovering and exploring the feature. There could be some kind of indicator widget in the status bar, maybe with a pop-up bubble the first time (and only the first time) automation is detected, to make users aware that there is something new they can do.

Well it seems there was something problematic with my installation, because I updated to the latest SVN, exported the normal map from GIMP in BC5 format, and it works fine in game. I'm not sure what the problem was before — perhaps I was just testing with a game DLL which didn't have the latest changes. BC4 definitely doesn't work but according to the description here, this is a 1-channel format so it wouldn't be expected to. I'm pretty sure I tested all of the GIMP formats the first time, but maybe I was just being dumb and tested BC4 multiple times but never tried BC5 @duzenko I've uploaded the images here if you want to confirm that the formats are correct. The diffuse is DXT1 and the normal is BC5, although in this particular case I would probably keep the normal map as PNG since this is less than 10% of the size of the DDS (because it's a smooth gradient normal map which compresses well with PNG). @MirceaKitsune Feel free to download the linked archive and see if you can open the _local map. I'm 99% sure you will be able to because I can read and write it fine on Ubuntu using GIMP.

Sure, I'll see if I can dig out the normal map. I'm sure it's something I'm doing wrong, like not using the right compression format or using an out-of-date or broken DLL version.

I think you're confusing the Game Connection feature which @stgatilov introduced recently, with the "Connect entities" command which has existed in DR from the beginning. Game Connection is a tool which allows you to synchronise the game camera position with the camera in DarkRadiant. It is not related to connecting entities.

I took a normal map which was working, then saved it using the GIMP plugin in 3DC+ format (I also tried using the Compressonator with various formats which looked like RGTC, e.g. "ATI2N"). After this, the normal map would either show only a single channel (e.g. horizontal bumps are visible but vertical bumps are missing), or no bumps at all; I don't recall exactly which.

Supposedly yes (I believe it's equivalent to "3DC+" in the GIMP plugin), however as I mentioned I have not been able to get this to work at all with the latest build. Only plain DXT-compressed normal maps render correctly.

Note that I have made a couple of minor improvements to the GUI. There is no full-fledged management widget or anything, but you can quickly enable/disable the camera sync or move the DR camera to the current game position using buttons on the camera view toolbar. I also rationalised some of the menu options, so enable/disable is a single toggle rather than two separate menu entries.

We're already using DDS format, and have been doing so since the initial release of the mod. The recent comments in this thread are about using RGTC compression within DDS for normal maps, which should give better quality than regular DXT1 but is not necessarily as widely supported by editing tools.

As long as the aspect ratio is the same, changing texture resolution alone should not break existing FMs. The compiled map (along with all models) will be storing texture coordinates as 0 - 1 normalised UV coordinates, which don't care about texture resolution. I believe the problem @AluminumHaste is referring to is that the actual visual alignment of certain textures has been changed, which means that they would need to be reapplied manually in DR by the mapper. This would make a direct image replacement unsafe.

"You may not include any Thief2X resources in any fan mission package" seems pretty conclusive. They are not granting permission to use their assets even within fan missions in T2, so there is obviously no general permission to include their assets in a completely different game.

Right now most GPUs are practically impossible to get hold of. There seems to be some global supply shortage. Amazon are currently listing an RX 550 (which I wouldn't use for anything more than web browsing and video playback) for over £220, which is more than I paid for my nearly-top-of-the-range R9 290 several years ago, and almost as much as 5600 XTs were selling for a few years ago. I haven't seen anything available in the mid-range affordable price bracket since the beginning of Covid. It's either ridiculously inflated bottom-dollar GPUs or the totally unaffordable super high-end.

Indeed, I'll give them credit for making it somewhat believable. They might want to improve their targeting though. If the objective is to sell women's cosmetics, a forum full of male gaming nerds probably isn't the most effective audience.

I wonder if this is going to turn out to be one of those tag-team spam threads, where one person asks for a recommendation and then their mate shows up 24 hours later to post a link to the desired site. Do girlfriends really ask their boyfriend to buy "some make-up" without specifying what they actually want (surely make-up is a very personal decision, not something you want an uneducated buyer to surprise you with), and since when do gamers use £4000 professional-grade workstation graphics cards? Apologies to the OP if this is for real, but these are some very unusual requirements.

Indeed, that would be the scientific way to do it, and very interesting if it ever happened, but I wasn't going to suggest it because there's no way it could ever be done given the ethical concerns you mention. Which does unfortunately lead to one of the fundamental paradoxes with social science research — "We can't test whether X is dangerous because we'd have to expose people to X which might be dangerous, therefore the experiment would be unethical. As a result, we just have to assume X is dangerous without ever knowing the truth!". The problem with this is that there is no way to separate cause and consequence. It might be that speech campaigns by far right organisations cause violence, but it might also be having a large number of far right individuals in a town causes both "hate speech" and violent attacks in parallel without an actual causal link between the speech and the violence (they are both consequences of a common cause). So unlike the interventional study, this "observational study" would not yield valid results. You are right, although this wouldn't be definitive proof (it is technically a post hoc fallacy), it would provide evidence if there was a consistent and widely reproduced temporal link in a large number of settings. If event B happens almost every time A happens, and there is no other obvious reason for the temporal correlation, it does point to a possible causal link between A and B which is worthy of investigation. But you'd need to be careful to distinguish between a causal relationship and just an "informational" one — did the speech cause the violence or was the speech just an indicator of some upcoming violence (perhaps by the same people who published the speech)? Are we looking at cumulonimbus clouds which cause thunderstorms or altocumulus castellanus which merely indicate they are likely? That would be interesting background information, but it's important not to extrapolate from "agreement with statements" to actual violence. There is a huge difference between somebody reporting that they have a different view of someone's rights, and actually committing violence against those rights. I wouldn't consider that a flaw at all. I would much rather see actual evidence-based policy making which changes in response to new evidence, rather than dogmatic faith healing which is assumed to be true no matter what. We should of course point out that even if we did all these experiments and gathered proof that speech could cause violence, this would still only be half of the puzzle — it would also be necessary to prove that laws against speech are effective at reducing violence. Even if you do, after all, prove that X is dangerous, you also need to prove that your laws will actually reduce the incidence of X, rather than increase it (by psychological backlash), drive it underground where it is even more difficult to keep track of, or just be widely ignored. Good catch. I never really thought of it like that, but I guess it is inconsistent not to demand evidence for restrictions on direct calls for violence. I suppose I'm not so bothered about this because specifically calling for violence is easy to identify, not likely to be confused with anything else, does not have any fundamental value in terms of discussion[1], and laws against it cannot so easily be abused to forbid dissent from an ideology in the same way that generic "hate speech" so frequently are. But there are forms of expression which could literally be interpreted as calling for violence (e.g. "#KillAllWhiteMen") which I don't think should be criminal acts, so perhaps it is better to keep an open mind even in this category. [1] Although this is a dangerous argument to make — some people would argue that dirty jokes and porn don't have any value in terms of discussion, but that isn't a good reason to outlaw them.