Hi Wojtek, On Thu, Apr 14, 2011 at 12:23 PM, Wojciech Lewandowski <lewandow...@ai.com.pl> wrote: > I hope I do not spread misinformation, as I am not fully sure nor I know > exact details but I believe that logic for finding if DXT1 pixels are > transparent, should first check the order of entries in chunk( 4x4pixels) > micropallete. And if its ascending then chunk may not contain alpha pixels > and if its descending chunk may contain such pixels and then we should look > for proper alpha pixel index. That information comes from top of my head, I > cannot at the moment delve deeper and look into verifying this but thats > what I remember I read somewhere...
This only applies to RGBA variant of DXT1 (DXT1a), the RGB variant (DTXc) has black pixel in place of fully transpent pixels. The links I provided discuss how the format works, and I'm pretty confortable with the actual DXT1 format now, and where the problem lies. The heart of the problem is that the DDS file format doesn't distiguish between the two varients of DXT1, there is an alpha bit in the DDS header that could be used, but 3rd party tools like nvdxt and nvcompress that write DDS files don't set this bit so both DTX1c with black encoded pixels and DTX1a are essentially identical in terms of header and content. Whether a particular file is DTX1a or DXT1c is entirely implicit and only known by the creator of the imagery. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
