Back squares in mip maps

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using pre-compiled compress.exe from Nvidia site (same issue occurs when
building and linking the source into my own application) 
2. Type "nvcompress -bc1 -nocuda test.tga"
3. Open result in DirectX texture tool viewer and notice that mip 4 and 5
have black squares in the compressed output.

What version of the product are you using? On what operating system?
Texture Tools 2.07 

Please provide any additional information below.
If you use the "-fast" option, you do not get these artefacts. (I do not
have cuda enabled, so I cannot test that path)

Other compression formats (bc2,3,1a) do not seem to have this problem.

Original issue reported on code.google.com by dtrebi...@gmail.com on 10 Mar 2010 at 12:43

Attachments:

• test.tga

[GoogleCodeExporter]

Ok, I think I have found the problem.
In nv::SlowCompressor::compressDXT1 there is this code:

if (rgba.isSingleColor())
(
  OptimalCompress::compressDXT1(rgba.color(0), &block);
}
else
{
 //Do squish compress
}

Now, if you have a 4x4 block with all the same RGB values, but different alpha
values, the code will take the squish compress path. The squish compress path 
does
not seem to be able to handle flat solid colors (a divide by zero?) 

There are two obvious solutions - Set the source alpha to a single value when 
doing
DXT1 compression, or update the above isSingleColor call to take how many 
parameters
to check (and update the code in all the places - quick and fast compression 
areas etc)

I have attached a simple 4x4 image that has red as RGB and variable alpha - the
result is a black texture when using the compression tools.
(I am very surprised this has not caused issues before)

Original comment by dtrebi...@gmail.com on 10 Mar 2010 at 1:49

Attachments:

• Test2.tga

[GoogleCodeExporter]

Thanks for investigating the issue, I can confirm I see the same problem. That's
strange, isSingleColor is supposed to compare only the RGB components, there 
must be
a bug...

Original comment by cast...@gmail.com on 10 Mar 2010 at 7:54

• Changed state: Accepted

[GoogleCodeExporter]

Oh, I see the problem, this was fixed in trunk:

http://code.google.com/p/nvidia-texture-tools/source/browse/trunk/src/nvimage/Co
lorBlock.cpp#162

but not in the 2.0 branch:

http://code.google.com/p/nvidia-texture-tools/source/browse/branches/2.0/src/nvi
mage/ColorBlock.cpp#114

Original comment by cast...@gmail.com on 10 Mar 2010 at 8:04

[GoogleCodeExporter]

OK, this is now fixed after the 1041 revision.

Original comment by cast...@gmail.com on 10 Mar 2010 at 8:09

• Changed state: Fixed

[GoogleCodeExporter]

Side issue, just looking at that code in truck the isSingleColorNoAlpha() I 
can't
imagine what it is trying to do, but it will always return true.

The "i" variable is not being reset once it reaches 16. Even then I don't know 
what
it is trying to do. (I would think this method should be deleted if the main
isSingleColor does not compare alpha)

Original comment by dtrebi...@gmail.com on 10 Mar 2010 at 8:34

[GoogleCodeExporter]

That code does not really do anything and is never used. I probably was thinking
about something, started copy-pasting some code, but never finished it, since I
decided that function was actually not needed. I should probably remove it to 
avoid
the confusion!

Original comment by cast...@gmail.com on 10 Mar 2010 at 8:46

[GoogleCodeExporter]

I've modified the code to do what I think was intended to do, but in any case 
I've
commented out the code since it's untested.

Original comment by cast...@gmail.com on 10 Mar 2010 at 8:50