Jump to content

  • Log In with Google      Sign In   
  • Create Account


Anisotropic filtering : Safe to assume with PS_2_0?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 NewDisplayName   Members   -  Reputation: 359

Like
0Likes
Like

Posted 27 December 2012 - 11:12 PM

Hi folks,

 

I have been using a (Min,Mag,Mip) all Linear, in my effects file. With a ps_2_0 compile option, can I assume that my GPU will always be capable to support Anisotropy? I know that it's always safer to define an alternate 2D sampler for anisotropy filtering, and use that technique when GPU caps indicate the anisotropic support. But isn't ps_2_0 already sort of ensuring those capabilities?

 

On a side note, I am observing a pixel-wide edge on top and left of my rendering window, which kinda looks like some sort of noise that is imitating the main window. Is this some filtering related issue or something else?

 

I am using direct3d9 APIs for rendering.



Sponsor:

#2 Nik02   Crossbones+   -  Reputation: 2764

Like
2Likes
Like

Posted 28 December 2012 - 07:10 AM

ps_2_0 does not guarantee anisotropic filtering capability, but in practice most ps 2.0-capable cards are capable of at least one degree of anisotropic filtering. Do remember that the maximum anisotropy degree (effectively, the root number of sample taps) is still variable, so you should check it anyway. Some drivers disable anisotropic filtering if you set the degree too high for the hardware, and this would cause visual quality issues.

Edited by Nik02, 28 December 2012 - 07:11 AM.

Niko Suni


#3 Nik02   Crossbones+   -  Reputation: 2764

Like
1Likes
Like

Posted 28 December 2012 - 07:13 AM

As for your side note:

-Are you drawing directly to the backbuffer or rendering via an intermediate texture?

-Do your render target dimensions exactly match the client area of the window (which is often not equal to the total window size)?

-If you do render to an intermediate render target before "blitting" to backbuffer, do you take into account the half-texel offset required to align the source and destination pixels 1 to 1?

Edited by Nik02, 28 December 2012 - 07:16 AM.

Niko Suni


#4 NewDisplayName   Members   -  Reputation: 359

Like
0Likes
Like

Posted 28 December 2012 - 11:22 AM

Thanks for the response Niko. About the Anisotropy deal, I am much more convinced about my approach to the filtering schemes, as per your suggestion.

 

For the side note, well I am simply rendering the local cam capture frames in windowed mode. There is no "blitting" involved, I am simply picking up the texture from the channel which is the one on which the captured frames are being delivered. As for the render target dimensions, I am doing a GetClientRect for calculating the backbuffer dimensions.

This one is a real puzzle for me now. I have been at it since months now, but can't seem to understand that why I am getting these noisy edges only on windows, but not on Mac (using OpenGL there), when my rendering flow is exactly the same for both platforms.



#5 NewDisplayName   Members   -  Reputation: 359

Like
0Likes
Like

Posted 31 December 2012 - 07:54 AM

Btw, this issue got solved. I found out that pixel offsets were not being calculated properly for Vertices. Used the standard +1/height, -1/width correction logic and works well now. This thread may be marked as solved and closed now.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS