Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Dghelneshi last won the day on March 3

Dghelneshi had the most liked content!

Community Reputation

31 Excellent

About Dghelneshi

  • Rank

Profile Information

  • Ingame Username

Contact Methods

  • Steam

Recent Profile Visitors

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

  1. There are literally dozens of different anti-aliasing methods, though most of the newer and cheaper ones operate in screen space after the image is already rendered, which is not the case for SSAA and MSAA. SSAA is the first and easiest to understand since it essentially renders the game at a higher resolution (multiple "samples" per output pixel) and scales it back down to the output resolution similar to how you would scale an image in Photoshop. This eliminates aliasing across the entire image, but is obviously very expensive. MSAA optimizes this method by first testing how many different triangles are intersecting those sample points within each pixel and then only computing the shading for at most one sample per individual triangle. This effectively limits MSAA to the edges of geometry, which is the place where most aliasing happens (especially in old games; unfortunately, during the last 15 years or so shader aliasing became a major problem as well). Foliage, chain-link fences, grates, etc. are usually made using alpha-test textures, which means the geometry edge is not where the visible part of the object ends since it's just a transparent texture on a much larger surface. Thus MSAA by itself will not help with the aliasing here, but there are ways to manually make use of the texture alpha to explicitly tell the MSAA implementation "hey I want this pixel multi-sampled" (this is called "Alpha-To-Coverage"). Both SSAA and MSAA can use different patterns for the extra samples per pixel. A regular grid is the easiest to implement in hardware, but if the geometry edges align with the pattern (i.e. nearly horizontal or vertical lines), there will still be visible aliasing. Thus many different variants were introduced like rotated grids or semi-random distributions. MSAA can additionally vary the amount of samples used for testing how many triangles intersect this pixel (coverage samples) and for computing the actual shading (color samples) as the former are very cheap in terms of performance compared to the latter and can improve the results by weighting the color samples more accurately (examples of this are called CSAA [Nvidia] and EQAA [AMD]). I'm not sure, but that sounds to me like you're reading about the generic theory of image resampling (how to scale an image from one resolution to another), which happens to be the last part of the SSAA/MSAA process. Surprisingly, downscaling is an incredibly difficult problem even though you have all the information available. It's almost impossible to tell which information is or is not "important" to preserve during this process so that the end result neither looks excessively blurry nor has additional artifacts that weren't in the original (e.g. aliasing, ringing). Regular SSAA and MSAA as implemented in the hardware will by default just use a simple average of the samples within each pixel ("box filter"), but some other variants have been introduced over the years as well.
  2. Dghelneshi

    Silverlight - Wins way too many games by organizing his team, even though he sux. 😛 Pushwall - Best Pilot, always knows what to do. SilverShark/Totd - Would be the best player if he didn't care about his K/D so much.
  3. Dghelneshi

    Afaik it's also currently not possible to have multiple of the same production facility, so good luck getting 15 players onto a single airfield.
  4. Dghelneshi

    Tested on 3 different maps, it always takes pretty much exactly 28 seconds.
  5. Dghelneshi

    If it's the .NET installer failing there's not much we can do about it since that isn't our software. Maybe this helps? https://blogs.msdn.microsoft.com/varungupta/2010/06/22/troubleshooting-net-framework-4-install-failures/
  6. Dghelneshi

    Could you upload the crash dump? You can find it by clicking on "User Data Folder" in the APB tab on the launcher, inside there should be a "debug" folder. Upload the newest file only. New HW seems decent so far, but we'll have to wait for more games with higher player counts. Low player counts make it very difficult to judge things since you might miss a cruiser going across the map and it will kill all your stuff before you can react, especially without Engineers. Unless I'm forgetting something we currently only have one map with both MiGs and Cruisers and then one other map for each unit seperately, which is a bit sad since we really want to show off those new units.
  7. Dghelneshi

  8. Dghelneshi

    After this fix, performance should be universally better than before 3.0. If your performance is worse than expected, check whether you have Anti-Aliasing on, particularly if you're on an integrated GPU ("MSAA Mode" in the launcher game settings or Options -> Configuration -> Performance -> Expert in the ingame menu). That option did nothing before 3.0, so you might have enabled it at some point without noticing.
  9. Dghelneshi

    From what I could find the problem with using BC7 for modern games is not just encoding speed for the large amount of textures, but mostly the sheer install size. With digital distribution, open world games, mobile games, etc. on the rise, this is a major concern (also in terms of loading speed, not everyone has 50GB of free space on an SSD yet, nevermind consoles!). Up until recently many engines also were designed with PS3 and Xbox 360 in mind, which do not have BC7 support, so all of this may be changing as we speak, there can be a surprising amount of inertia in certain parts of game tech. Most of your textures will be RGB with no alpha though, where the size delta to BC7 would just be too large. If you have very high res texture sources (which we usually don't, but AAA games do) and apply compression to your game files (which we don't do yet, but it's on the TODO list), you will get much higher quality out of your texture by just using BC1 at twice the resolution (4x uncompressed size) instead of BC7 (so 2x compressed size). You'd still have 2x the VRAM cost, but since BC7 has much higher information density, the disk size difference after using zip compression shrinks to something like 1.35x, so that might be worth it overall and the improvement in fidelity is enormous from the resolution (just did this on one texture for testing, size difference may vary depending on content). With the "clustered DXT" of Crunch and its commercial successor Basis there is a lot of additional work being done to make texture data even more compressible so that install sizes can be smaller even if VRAM usage stays the same (though quality suffers slightly). Quite a lot of games (including the Unity engine) have adopted these advanced modes of Crunch into their pipeline and since Crunch doesn't do BC7 this is another hurdle towards its adoption, though once Basis is more established this might change since it does have support (it's not free though). Edit: One good application for BC7 might be UI textures where quality and sharpness is very important, alpha is commonly used and BC3 often fails miserably. Many use uncompressed textures here. Note: Added a small note about mipmaps to the OP (below the ranking).
  10. In this tutorial I want to teach you how to get the best quality out of your textures when compressing them. What is DXT? DDS is a container format designed for texture data and can have different amounts of compression applied (including none). There are 3 major compression formats defined in the Direct3D 6 standard: DXT1, DXT3 and DXT5. These are also called BC1/2/3 ("Block Compression") respectively. Later versions added BC4/5 (D3D10) and BC6/7 (D3D11). Each of these have their own use cases and advantages, so higher numbers are not just "better" versions. The advantage of these compression formats compared to something more common like JPEG is that they can be uploaded to the GPU directly and always stay fully compressed in GPU memory. With hundreds of megabytes of textures this adds up quickly and allows us to improve performance (less memory bandwidth used) and target lower end/older GPUs with less VRAM. The decompression is implemented directly in hardware and happens transparently on memory access. The key ingredient for this to work is that the format is made out of independent 4x4 blocks of pixels that can be decompressed individually instead of the entire texture at once. A more thorough look at the details of the compression formats can be found here: http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/ Which Format to Use? The DXT-Formats mostly differ in their handling of the alpha channel (usually used for transparency). Use BC1/DXT1 for pure RGB textures or hard "cut outs" which only need one bit of alpha (fully opaque or fully transparent) Use BC2/DXT3 for RGBA textures with discrete "hard" alpha transitions (this format has 4 bits of alpha per pixel, so 16 different levels of transparency) Use BC3/DXT5 for RGBA textures with smooth interpolated alpha (use this over BC2 unless you're certain) The data rate is constant regardless of image content: 4 bits per pixel for BC1 and BC4 and 8 bits per pixel for every other format. This means that BC1 should be used where applicable to save memory, don't forget the 1 bit of alpha comes (almost) free! BC2 use cases are rare, usually you probably want BC3. A nice overview of features and use cases for all BCn formats can be found here. Missing in this table is a particular trick for using DXT5 for better quality normal or bump maps explained here, also called DXT5nm or DXT5-xGxR and has direct support by a few tools (e.g. NVTT, see below). The more modern BC4-7 formats should generally be avoided for now since the older Renegade-compatible W3D engine can't load them at all, W3D 5.0 (APB, AR and BFD) can't load them yet (though afaik it would be trivial to add support) and most importantly, 3ds Max and many other programs cannot open them (BCn App Support). Nevertheless, we might have a specific need for one of these formats in the future that warrants their use despite the tooling issues and we can always just use the uncompressed source texture for the .max files. At some point in the future, I will specifically take a look at BC5 for optimum quality normal maps and general BC7 vs. BC3 quality since it should be tremendously better in most use cases at the same size. BC7 instead of BC1 should not be used frivolously due to being twice the size and also less amenable to further compression (e.g. zip) since it actually carries so much more information, but when you really need a near-lossless result, this will do it. Since the BC7 format is so much more complex, some encoders can take many hours for a single texture at high quality, but there are some faster ones out there (see below, so far I only tried Compressonator for BC7, will revisit this at some point). Which Exporter to Use? This is where we get the reason why I wrote this post in the first place. I noticed some textures looking awfully blocky ingame with obviously off-color artifacts, which was caused by an extremely bad DXT encoder. I then set out to compare different compressors and stared at textures for hours (I also used PSNR metrics, but visual inspection was much more useful). In total I tested 7 different tools with two DXT1 textures we had uncompressed sources for. First of all here's my personal ranking in terms of output quality: Crunch (download can be found here in the "bin" folder) tied with Nvidia Texture Tools (NVTT, download from "releases") Compressonator (download from "releases", also see here for Win7/8 issues) Paint.Net (https://www.getpaint.net/) GIMP with DDS plug-in (https://www.gimp.org/ and https://code.google.com/archive/p/gimp-dds/downloads) DirectXTex (download from "releases") DDS Converter (http://www.ddsconverter.com/, but I'd rather you throw it deep into the sea) To motivate you to switch from a different tool, let me detail the issues encountered with the different encoders (comparison images are in the spoiler below). Edit: No matter which tool you use, make sure it generates mipmaps. Some will do this by default, some don't (Compressonator). Some tools also offer the ability to specify gamma/sRGB for mipmap generation. With the current renderer this should be set to sRGB/2.2 (default for Crunch and NVTT). If you're unsure about gamma, use a checkerboard texture to replace a terrain texture ingame, disable anisotropic texture filtering and look off into the distance, with proper gamma it should look about medium gray (with lighting taken into account), otherwise it will look darker (like here). Edit2: If you're working with tiled textures (terrain, walls), make sure you're telling the compressor so it doesn't break the smooth tiling (e.g. -wrap for Crunch, -repeat for NVTT), though the difference is usually minimal. Crunch was originally developed for a more advanced purpose, so make sure you only use the command line options that produce a "normal" non-clustered output (in particular, do not use -bitrate or -quality). In terms of visual quality, it particularly excels at gradients and dark areas. NVTT is very close overall, with Crunch displaying better performance on gradients, while NVTT beats it at high-frequency detail. Note: Do not use this tool for BC7, unless you want to literally wait for days for a single texture even with the "fast" encoding option. Compressonator is one of the few tools to feature both a GUI and a command line interface, although the GUI can a bit weird to use. Make sure you generate mipmaps explicitly and set the quality to 1.0. In my experience the quality is always slightly behind Crunch/NVTT, but it's definitely not bad and it has been recommended a lot in the past. It was the only tool I tried that could output BC7 within a reasonable amount of time (35 seconds for a 4k texture with quality=0.05, though without comparison I can't speak for its visual quality). Paint.Net is not terrible but very clearly behind the other options. Gradients and dark areas suffer from banding and block artifacts and some areas appear darker than in the source or have their hue shifted to a different color. The uneven gradients make the "block" structure of the compression very visible. GIMP first disappoints with a "use perceptual error metric" option, which for unknown reasons makes the output worse rather than better. The output doesn't impress either way though, with even worse gradients and random hue shifts than Paint.Net. Surprisingly, it does fairly well at high-frequency detail, but that in no way makes up for its general poor performance. DirectXTex from Microsoft may sound like a natural pick, but sadly it is one of the worst encoders I have seen so far. Simple flat areas turn into a blocky mess of different colors that weren't in the source at all, gradients look horrible, etc. As with GIMP, it does fairly well at high-frequency detail, but in doing so it introduces severe noise across the entire texture, sometimes looking a little bit like the JPEG artifacts we all know and love. This compressor also supports BC7, so I may come back to it in the future. DDS Converter I haven't tested directly, but it was the source of the problems that caused me to investigate this issue in the first place. The quality is just godawful, in some parts it almost feels like the texture is lower resolution than it really is because entire 4x4 blocks share the same color for no particular reason, and it's not even the correct color! In addition, some detail introduces harsh artifacts and noise. I weep for all the people googling for "dds converter" and having to put up with shit quality textures because of this tool. Unfortunately, I haven't been able to take a look at the ISPC Texture Compressor yet since the provided GUI tool lacks functionality and there is no CLI available, so I'd have to write my own. They also offer a Photoshop plugin. I would expect similar quality to the top 3, but can't know for sure. Another tool I want to look at in the future is bc7enc16, a prototype for a full BC7 encoder. Comparison images in spoiler (Open up in full size! Note that some issues like darkening and discoloration are more visible in context): There's probably a lot more stuff I could talk about, but for now I've run out of gas. Any questions/suggestions are welcome.
  11. Dghelneshi

    That might be an interesting option, but they would have to be framed differently since the purchase icons are square and ideally have some sort of common style.
  12. Frank has high quality versions of the tracks streaming on his website, so they definitely exist!
  13. Dghelneshi

    WTF kind of CPU do you have that doesn't straight up shut down at 101°C?! That's an insanely unsafe temperature.
  14. Dghelneshi

    "Stair lag" is just a term I made up for the warping that happens regularly when you try to go up stairs, even on 0 ping. It's not an issue specific to stairs, it's just so incredibly frustrating to try and run up the WF or Refinery stairs for emergency repair and then end up at the bottom again after half a second.
  15. Dghelneshi

    Whoever fixed that is a hero. Now, if someone can fix stair lag and warping then we need to erect a statue or something...