0
\$\begingroup\$

I am trying to implement dual-pass alpha sorting using Ogre material scripts, as part of my debugging attempts I want to compare two PIX captures, but when I attempt to debug a pixel in PIX, previously working 'geometry' is not displayed correctly.

My 'reference' blended geometry which works consistently, consists of a simple box with a translucent material, sitting over a set of opaque primitives. In my app this displays fine with the 'smoked' box tinting the objects/pixels behind it. When I load up my app starting through PIX this continues to work, but once I load a capture taken from this in PIX, it no longer blends the pixels and instead culls them.

I know it is PIX because in the debugger tab, I see the initial value of the pixel I am debugging is the correct blended colour, but the final frame buffer value is the darker incorrect colour - its as if PIX is 're-rendering' the shot and doing it wrong!

Could anyone suggest a reason for this behaviour?

\$\endgroup\$

1 Answer 1

0
\$\begingroup\$

If the reference rasterizer displays it correctly, then your code is correct and it is a bug in PIX.

\$\endgroup\$
1
  • \$\begingroup\$ Hi, It is a rare day when I actually get to attribute problems to someone else's code! ;) I have managed to implement dual-pass alpha sorting, short of Ogre doing something clever along the lines of combining multiple frames (would Pix pick up on that) I don't see what else it could be. I am glad someone else confirms it, thanks! \$\endgroup\$
    – sebf
    Aug 15, 2011 at 7:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .