Sign in to follow this  
Guest

The nVidia bug

Recommended Posts

Hi Bob and allHere some words out of Martin Wright's "DXTBmp" tool. The nVidia codec used to save Extended images has an obscure bug that can cause a failure to save with certain images when DXT1 Opaque+Alpha is used. In these cases the internal method of saving can be used. This may give a slightly lower quality image so should only be used when the normal save failshttp://flightsimmers.net/airbase/petercie/images/mip.jpgIn the middle of this screen there are 2 textures where the nVidia bug occured by using "DXTBmp" So I saved "DXT1 with alpha non nVidia" The mips are looking good in DXTBmp. But in this screen they are bad coloured.A reason may be, that the slice-bitmaps are RGB made from indexed colours.It seems that the ACT and the Oslo scenery (see this forum) could have better textures, if made alpha with nVidia.Pit

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

If working from true 24 bit data then the internal routines are only marginally lower quality than the nVidia codec. Usually for things like ground textures you won`t notice much difference.However when working from dithered 8 bit images it suffers badly. This is because the compression code is a lot less complex than the nVidia code and doesn`t apply any pre-filtering to reduce the problems that a dithered image will have.I can only assume you are only able to obtain 8 bit image data for your source bitmap. As an experiment you could try using DXT3 for the "problem" tiles. This would let you use the nVidia code.

Share this post


Link to post
Share on other sites

Thanks Martin, that helps...I was shaking my head. I have always worked with 24 bit images, so that must be why I couldn't understand how the quality could be so bad, mine always look fine.Bob B

Share this post


Link to post
Share on other sites

8 bit is a problem. No matter how good it looks it creates the illusion of many colours by dithering the 256 it has.Because DXT compression works on averaging the colours in 4x4 blocks the dithering can mess this up.Usually the main image isn`t too bad but the mips get progressively worse. Especially with my internal code which uses a fairly simple scaling algorithm to create the smaller images. Scaling 24 bit and scaling 8 bit are 2 entirely different things. With 24 bit you can halve the size of an image by taking each 2x2 block and calculating an average colour for when this is reduced to 1x1. With 8 bit the pixels may bear no relation to the required colour. For instance what looks "medium brown" in an 8 bit image may in fact be created by dithering shades of red and yellow. When this is scaled down you may get an average colour much closer to red or much closer to yellow (depending on the dithering in that part) but you probably won`t get brown.I remember in the early (pre-nVidia) days of repainting CFS2 Aircraft with DXT1 textures. People were coming up with some horrible results but it turned out that they were converting to 8 bit at some stage. Even if you convert back to 24 bit the dither remains forever...

Share this post


Link to post
Share on other sites

Thank You Martin.My textures are my good old FS2000 indexed textures, set to RGB.I tried DXT3 Alpha with DXTBmp. But I got nVidia bug too.In DXTBmp Preview the non-nVidia mips look fine. Is it possible to make this Previews with real non-nVidia?Working with photoshop-filters will make a fine texture but bad mips using non nVivia.You can save a image with DXTBmp only one time. You can not overwrite. (no problem)Pit

Share this post


Link to post
Share on other sites

There isn`t actually a preview for the non-nVidia DXT1. The preview mips are created using the nVidia code.You shouldn`t be getting a bug warning with DXT3. I have never seen it happen myself. All nVidia coding *could* conceivably trigger the warning if it causes an error but I have never seen it happen except with DXT1. I would be interested in seeing the image that does this. Whatever the internal error is I suspect it won`t be the same as the DXT1 one.If you are not using any water areas then Batch conversion can be done using my ConvIm program. If water (ie Alpha) is involved then my ConvDXT program will batch convert without error....but it uses the same internal code as DXTBmp to avoid using nVidia so that won`t necessarily solve the mipping problems.The one suggestion I didn`t mention before is to pass the "troublesome" images through Imagetool. If a conversion fails then save it out as a Targa from DXTBmp then load it into Imagetool and change the format to DXT1 and then create the mips.You need the Imagetool from FS2002 Pro to do this (unless they have included the newer version with any of the recent sdks)I`m afraid working from 8 bit sources is always going to be difficult. I can only assume that the nVidia code includes some fairly complex "de-dithering" code to deal with it. I junked most of my DXT code when the nVidia codec became available (and gave results that were so much better). I had to dig it out again when the "bug" surfaced so at least there was an alternative option in these occasional cases.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this