[vtkusers] Depth Peeling VTK5.2 ATI Cars

[Sean McBride]

On 10/3/08 9:01 AM, Inigo Barandiaran said:

>Thanks goodwin for your reply.
>I tested depth peeling in both laptop and non-laptop PC. With an old ATI
>card and with a New ATI card with the lastest drivers installed (i used this
>tool http://www.driverheaven.net/modtool.php that allows to install the
>lastest ATI drivers for non-Laptop PC in any laptop).
>
>Depth peeling did not work nor in laptop neither in non-laptop PC. 
>
>Francois, i don't know where is exactly the problem. In your code, you
>mention that the problem is the implementation in GLSL of some funtions in
>ATI's driver isnt it?

This problem also reproduces with ATI cards on Mac OS X 10.5.5 (the
newest) and older also (at least back to 10.4.8).

I filed a bug with Apple in February 2007 (bug #4975997).  After a long
while, Apple/ATI replied that they think it is not an ATI bug but a VTK
bug.  They said:

"From looking at the test yesterday it is our understanding that two
different rendering methods are being compared. The results of the
original method has been stored as RGB8 (integer) in a 300x300 image,
i.e. we are comparing the variation of 90.000 rgb triplets between two
numerical methods. After rendering using the new method the difference
image between the old and new method is calculated and the color
variation is summed up, if this exceeds a certain value the test is
considered to be failing. Each rendering method calculates the final RGB
value via a series of multiplyadds (blending) with the final result
being an ubyte, i.e. a round off or truncation happens somewhere before
the results of the two methods are compared (at least the result of the
original method has been rounded of before comparison). 

Not sure if the final comparison uses the color amplitude (grey-value)
of each pixel or if it compares the R, G and B values of each pixel
individually. However given that two different numerical methods are
compared after the results have been rounded/truncated in the
framebuffer (or by glreadpixels) it is no surprise that 1 in 18 grey-
values or 1 in 54 R, G, B value vary by a single bit (I have typically
seen an error of 4800, which corresponds to a 1 bit error of every 18th
RGB triplet)."

I have communicated this to François in the past.

>I will try to find a solution, but, do you think is going to be difficult to
>solve? Thanks in advance, and thanks for your efforts in VTK :)

I think it will be. :)

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada