Hardware RC4 antialiasing

[slaver0110]

Sorry if this has been covered before, but a cursory search didn't provide an answer.
I'm trying to set up the Nvidia 3D settings for Orbiter, and the only change I'm making is the addition of antialiasing; nothing else. An initial setting of 2x completely removes the jaggies from the 3d view, and all is looking good...
Except for the MFDs.
With AA enabled in the hardware drivers, the MFD's display properly, but the text in them is blurred in the 2D panel view, to the point of unreadability.
I'v tried various combinations of AA settings, but to no avail.
So, my question is, can someone propose a solution?

Quick specs (in case applicable):
i5 4670k OC'd to 4.5
32 GB system RAM
x2 GTX970 2BG in SLI (SLI disabled for Orbiter)
Orbiter RC4 with all HiRes Textures

Note: If there's no solution, I'd rather live with the jaggies in the external view, than not be able to read the MFD's.

Cheers!

 

[RisingFury]

Given my understanding of AA "under the hood", I don't think you'll be able to address that.

You'd have to render the 3D / 2D geometry with AA, then render text / MFD lines onto that without it. I think it's possible, but it has to be done in the code.

 

[Weirdo Earthtorch]

Just experimented a little. I found that the NVidia Control Panel "Antialiasing - FXAA" causes degradation to the 2D panel MFD text (although I could still read it). The 'regular' "Antialiasing - Setting" works OK and MFD text is unaffected, although the antialiasing is not quite so effective. This is with a GTX750Ti @1920x1200. :shrug:

 

[RisingFury]

FXAA - Fast Approximate Anti Aliasing is a post processing algorithm that takes a rendered image and filters it. It's much faster than MSAA, but produces bad results in some cases. I assumed you were using MSAA...

 

[Thorsten]

Basically driver-side AA can't know what you're rendering - it will operate on anything (including things like displays, menu bars, if they're rendered into the scene). This isn't in any way Orbiter-specific, it will happen for other software as well.

AA that specifically works for parts of the scene but not for others needs to be set up as a step of the rendering pipeline for the elements you want and left for those you do not on the C++ level. How (and whether) this works is thus hard-coded in the 3d application and not selectable by a driver setting.

 

[Ripley]

Maybe I'm completely off, but have you tried changing MFD's resolution from Launchpad's Extra tab?

 

[slaver0110]

Maybe I'm completely off, but have you tried changing MFD's resolution from Launchpad's Extra tab?

Yeah, toyed around with those settings as well; no luck there.

Spent an hour trying various settings in NVpanel, but again to no avail.
It strikes me as odd that AA affects only certain modes of text in the simulator. In VC, all panels read as clear as day.
The text that becomes blurred to the point of practical unreadability is:
* Text in the 2D panel MFD's.
* Text in the stellarium view (external), including base markers, etc.

Hmmm...I'm going to stay on this for a while, and see what I can figure out. As I said before, this isn't critical to me; just one of those things that sticks in my head until it's resolved.
Further, the way I see it, if I find a solution it may help someone else with the same problem.

Cheers!

 

[Thorsten]

It strikes me as odd that AA affects only certain modes of text in the simulator. In VC, all panels read as clear as day.

Because AA is by nature a rasterizing stage operation and designed to take care of rasterization artifacts, whereas textures come with mipmapping, ought to have their artifacts suppressed by that and are in any case only available after the rasterizer has done its job.

You need to have a basic idea of how a real time rendering pipeline works internally to appreciate that these are different situations.