Textures

[ShezA 176]

Guys, have been experimenting at various texture types DXT1&3, 444-4,888-8, 8bit 512x512 565, etc.What in your experience gives the BEST and clearest result for scenery? No Alpha channel required.DXT1 and DXT3 seem to give the same result for opaque textures. Anyone concur?ThanksShez

[Guest]

I have no final answer, and I'm not completely sure about this, but I've experienced that DXTs are at least faster than 565s.

[Guest]

Hi Shez you know I.ve found the the standard .bmp gives the best results(I beleve you have seen our CYQT scenery and I used mostly standard bmp's on my models with a few execptions) and it 's only when I used say dxt's that I had had "problems" with how the textures displayed due the the way FS handles mipmapped textures.I will attatch a pic showing how nice and sharp standard bmps displayin 2002. Please note all my textures are 256x256. Hope this helpsOpps sorry about the size of the pictures! Dan

[ShezA 176]

You are possibly right Dan but the problem I have is with textures created using many differing colours (i.e colours on the oppsite end of the spectrum). When you downsize the colours to 256 the resultant colours are 'fragmented' especially where a gradient is involved. Does not look particularly brilliant, especially the night textures.With the DXTs the 16bit colours mean that this is not the case.Comments?Shez

[Guest]

>You are possibly right Dan but the problem I have is with >textures created using many differing colours (i.e colours >on the oppsite end of the spectrum). When you downsize the >colours to 256 the resultant colours are 'fragmented' >especially where a gradient is involved. Does not look >particularly brilliant, especially the night textures. >>With the DXTs the 16bit colours mean that this is not the >case. >>Comments? >>Shez I have also very colourful night textures (windows etc.), with both dark and bright colours, and even DXT doesn't give me a sufficient result. I then use 16 mil. 565-format textures, which seems to be slower than the DXT ones.

[arno 1]

>When you downsize the >colours to 256 the resultant colours are 'fragmented' >especially where a gradient is involved. Does not look >particularly brilliant, especially the night textures. Indeed 256 color texture don't look good, especially on buildings with many colors etc. I haven't used 256 color bitmaps for a long time :).I think normal BMPs would probably give the best result, but I prefer to use DXT textures. They are smaller in size and are faster it seems. They might look a little less sharp, but I don't think that is a problem. Mostly I use 512x512 textures by the way.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest]

Understand what you are saying Shez and that's why I did use a few DXT textures but like I said I don't really like the way DXT's can give the blurries due to how FS handles mipmapping. Sorry but I have seen to many sceneries that display awfull blurry textures and so I at least will avoid mipmapped textures when ever I can as I hate blurry textures! :-eek

[arno 1]

All DXT1 textures (with mipmaps) and it doesn't look blury to me :).http://home.wanadoo.nl/arno.gerretsen/images/eham05.jpgAs you can see still work in progress by the way.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest GerrishGray]

Hi guys[ol][li]The first important point here is that any non-extended bitmap format without mips will have inferior performance in FS2002. The mips save a lot of extra work in resizing the image to the size required on screen. But I don't think that the performance hit is a big deal for a single object - it only becomes an issue if everything in the scenery uses non-extended textures, or the object is repeated lots of times. Dan is suggesting that plain Windows bitmaps seem to work well in these circumstances - which format did you mean Dan, 8-bit colour or 24-bit colour?However, all preferred formats for FS do now include ready-made mips to improve performance, and this is true of all formats described in the rest of these notes.[li]The FS2000 8-bit extended format, although supported, has some problems in FS2002. This is a pity because (a) it does give precise rendering of the required colours as long as the image does not need more than 256 separate colours, (:( it includes mips, and © it even allows a form of 8-bit alpha transparency (although most often it is only used as simple 1-bit on-off transparency). But the first problem is that the interpretation of this format by the rendering engine involves an extra level of work because the individual pixel values are merely an index into a colour palette table containing 256 separate 32-bit RGB values, so a 'lookup' has to be performed for each individal pixel. The second problem is that the rendering of any transparency from this format seems to cause the FS engine a problem and can result in an unpleasant shimmering effect moving across the screen in waves - nasty! But the format seems to work OK for non-transparent textures that only contain a few colours. It is unsatisfactory for images that originally had smoothly graduated colours because these will end up with 'banding'.[/li]This format is best created with Martin Wright's Bmp2000 utility, which offers lots of useful options. For all remaining formats, the best conversion tools are Martin's DXTBmp or Microsoft's own imagetool.exe. Each has its advantages.[li]The FS2000 8-bit format was developed as an economical alternative to the full 32-bit 888-8 format. Each pixel is coded with 32 bits of data, 888 for the 'true colour' RGB value and 8-bits for an alpha channel that can be used as graduated transparency (e.g. the clouds textures in FS) or for a reflective index when combined with the lighting effects offered by DirectX. But the file size is enormous and performance suffers seriously as a consequence. It is useful in FS for special applications such as the clouds, but too 'costly' for general use.[/li]That leaves us, for FS, with a number of extended bitmap formats using 16-bit colour. 16-bit bitmaps are only able to render a 'limited' range of colours because of the 16-bit per pixel format, so colour reproduction is not always accurate, but it should be adequate for most FS purposes. They come in two flavours: (a) non-compressed bitmaps in 565, 555-1, or 444-4 formats, (:( the compressed formats used by DirectX. Only DXT1 Opaque, DXT1 with Alpha, and DXT3 are supported by FS2002.[li]565 is the uncompressed format with no alpha channel. It gives slightly better colour depth than the others so it is the preferred choice when no transparency is required.[/li][li]555-1 provides a simple 1-bit on-off transparency channel.[/li][li]444-4 gives a 16-level transparency channel for partial transparency (haze) effects, but there is no point in using it otherwise because the colour depth is inferior.[/li]The DXT formats are 'native' to DirectX and give the smallest file sizes (because they use compression) and best performance (in terms of speed, that is). The compression is 'lossy', and the algorithms used for the mips are based on a blending technique that samples the bitmap in 4x4 pixel chunks, so tend to be blurry and can suffer from a 'bleeding' problem where one colour meets a contrastingly different one at a sharp edge. But the smoothing effect also creates some built-in anti-aliasing which can be beneficial for moving images in fast-moving games ...[li]DXT1 Opaque is the DXT version of 565. It offers small file sizes, using a fairly aggressive compression algorithm.[/li][li]DXT1 with Alpha adds 1-bit on-off transparency (like 555-1), with the same aggressive compression as the Opaque version.[/li][li]DXT3 offers a 4-bit alpha channel for 16-level transparency (or reflection on aircraft models). Like 444-4, the colour depth is inferior but, on the other hand, the compression algorithm seems to be less aggressive because file sizes are larger than DXT1, so there is presumably less loss of information than with DXT1.[/li][/ol]Which is best? Well, there is simply NO fixed, clear answer to that, it depends entirely on the circumstances! "Yer pays yer money and takes yer pick" as the old saying goes. 888-8 is needed for clouds, but otherwise FS2002 'prefers' the DXT formats because they are native to DirectX and give the smallest file sizes (which can have a considerable performance benefit in several ways). Perfectionists may find reasons for using other formats, but I have to say that personally, after a lot of testing, I prefer the DXT formats because I really can't see any appreciable difference between these and the uncompressed formats when rendered on screen by FS - and you all know that I'm quite a perfectionist myself where my trees are concerned!!! One also has to remember that we are talking about a FLIGHT simulator here with a graphics system designed for rendering moving images with minimum overhead, NOT a system for high-definition rendering of static images in an art gallery.RegardsGerrish

[ShezA 176]

GG, thanks for your comprehensive round up. As usual you have given a good account of your personal experience. I agree with you that DXT1 opaque seems to come out as the best compromise for non-transparencies. I think for building textures the technique is to make sure one uses 512x512 and to ensure clarity of texture by using smaller faces of the structure for large texture areas so the texture gets compressed on to the face, with all it's detail. This I find is the surefire way to ensure sharpness even with the DXTs. Of course practicality may not always be there.Shez

[Guest]

Hi all what I was trying to say is that I used mostly simple 8 bit 256x256 bit mapps in our scenery and (please understand what I am trying to say here) on my models all my textures look crisp and clear and all are the size of 256x256 even on large buildings like the terminal,like I said I HATE,simply HATE blurry textures! It'sall in how good ones textures are to start off with lousy textures you will have lousy looking models no matter what format or what size textures you use. (Just ask my bud Jim Kanold about how picky I am about textures!) Dan

[Guest]

Hey Arno please I am not trying to say "mine is better than yours" of course one will get good results with 512x512 textures and you may get better results with mipp mapping but then a 512x512 is at the very least 4 times larger than a 256x256 bit standard 8 bit texture and that as you well know can make a differance at a large airport. Your Netherlands scenery looks outstanding of course.Anyway I think that people might misunderstand what I was trying to say in the first place that I and others have had "problems" with the blurries when useing mippmaped textures that's all. PleaseI did not mean to offend anybody of course but I do stand by what I see when running the sim I and other people do get the above blurrieswhen using mipmapped textures. Anyway I have said enough on this and like I said I do not want to offend you or anybody else!. Dan Dan

[rhumbaflappy 113]

Hi Dan.To further confuse the issue, ImageTool will mip 8-bit to 9 mip levels, while it mips DXT1 to 7 levels. You can even force 7 levels for 8-bit, by mipping it as DXT1, then reformatting back to 8-bit!8-bit = 66,614 bytes8-bit 9 mips ( 2000 Extended ) = 88,479 bytes8-bit 7 mips ( Frankenstein ? ) = 88,474 bytes:-xxrotflmao Dick

[Guest]

Yup it can be confuseing can it not! Dan

[arno 1]

I didn't take it as an offend or so. The picture was just meant to show that it can also work fine with mipmaps, to prevent other people from thinking only negative about them.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...