   What conditions break anti-aliasing in D3D9?
  Hi,recently i've been doing alot of post processing stuff that involves rendering to floating point render targets. I'm also using StretchRect() in some places. Now, sometimes AA works, and when doing some other type of rendering, AA breaks (rendertarget recieves no AA). I had this problem before on my GeForce 6600GT, but wasn't very surprised because I know it can't handle multisampled fp rt's.I got a Radeon X1600 w/ 256 MB recently, and AA worked. It wasn't a big surprise either as one of the new features of the X1k-family is fp rt's with AA. However, I started playing around with more effects using StretchRect and rendering to fp rt's, and now AA won't work anymore. Big surprise for me ;)Is there any documentation from either MS, ATI or NVIDIA which specify what states and conditions must be met for AA to work? I've looked around but haven't found anything useful, especially regarding fp rt's. Most documents I've found regarding AA are too old. A simple list of which formats/operations are legal and not would do wonders for me :)Anyone know where I can find this information?Thanks in advance,Simon   
  I'm pretty sure straight render targets (rather than no stretch rect) will give you no AA. Also, the 'big' FP texture formats (R32FG32F etc) have no support for -any- filtering, so no aa there either. Sorry I don't know enough about the situation to comment better than that though :(   ;  Well, that's why I use StretchRect() to begin with. The idea is to draw your basic geometry (that you want AA'd) to a multisampled rendertarget (for example the backbuffer). Then you StretchRect() from that rt to another surface (for example a texture). That way you can apply cool effects to a multisampled rt.On the X1600 you can however, even use a multisampled fp16 (D3DFMT_A16B16G16R16F iirc) rendertarget.This works fine most of the time, and looks great, but there seem to be some conditions that break this. I just need to find out what those are so I can get my nice AA back ;)/Simon   ;  Ok, answered my own question. Found a paper on nvidia's dev site which states:Things that will Break or Slow Down AA• Back Buffer Locking• StretchRect()  – Can Force a down-sample• Z Buffer Locking  – Can Force a ‘down-sample’• Applying AA Zbuffer to Aliased Texture  – How is this supposed to work?  – Just Re-render your z buffer to be sure• Multiple EndScenes()Here it is if someone else is interested:http://download.nvidia.com/developer/presentations/GDC_2004/D3DTutorial_Sim.pdfNow I just have to find out which condition I break :P/Simon   ;  Conditions that break AA are different if you're using control panel AA or application enabled AA.As a developper you shouldn't rely on control panel AA. So I suppose you're talking of application enabled AA (via the D3D9 API).(as a side note AA on ATI's drivers is in a pretty bad shape, with things breaking on and off depending on the catalyst version. So you shouldn't totally base your code on what's breaking there.)It's easier to list things that are supposed to work in the API (not counting driver bugs): - rendering with a single (no MRT) backbuffer that is allocated with a multisampled flag with a depth buffer that is allocated with the same multisampled flag.- rendering with a single (no MRT) off screen rendertarget that is allocated with a multisampled flag with a depth buffer that is allocated with the same multisampled flag.- stretchrect from a multisampled rendertarget (either backbuffer or offscreen) to a non multisampled rendertarget texture or a non mulitsampled rendertarget (either backbuffer or offscreen).- getfrontbufferData from a multisampled swapchain.That's all that is allowed with your multisampled data. If you're trying to do anything else than that then it won't work (no texture, no lock, no mrt, no mismatched rendering). You also need to check if your format is supported as a multisampled target with the CheckDeviceMultisampleType method. But then creation would have failed anyway..LeGreg   