This is inaccurate: all our postprocess AA is handled by our own code, so we're not driver/manufacturer dependent. Multisampling is something we want, but under deferred shading (which we use) it's not a simple task. There are no DX10/11 features that would pretend to fix the AA, though handling the MSAA efficiently is most likely a DX11-only feature.
This is relevant to my interests. I can't quite visualise what you're describing but seeing screenshots of it would no doubt give us something to go on.
Hi
I haven't found the obvious possible flipped vertices, but I have found another example of some lighting anomalies along lines which looked aliased from a distance on one of the starports. I have attached three screenshots from differing (near) distances, the lighting artifacts are underneath the red/orange band on the right.
Links (Can't seem to upload them)
https://drive.google.com/file/d/0B-kqm_hXFyf5azB3bGlCblQ4Um8/view?usp=sharing
https://drive.google.com/file/d/0B-kqm_hXFyf5SFVCbDN6UVZnbjg/view?usp=sharing
https://drive.google.com/file/d/0B-kqm_hXFyf5bk80clc4TDJxa2M/view?usp=sharing
The AA settings used are:
Supersampling (SMAA) using dangerous32.exe driver settings override
Wide Tent
6x/8x
Card is an older AMD HD 5830 card (due to be replaced very soon) just about able to run Elite with medium settings
The station which had the possible flipped vertices/normals was one of the outpost models, I will keep trying to grab an image if I see it again when I go near them playing ED.
The more common aliasing issue (also visible elsewhere) seems to be some sort of screen space sampling/rasterization artifact cutting into the solid appearance of the geometry, maybe the cost of getting the environment to even run on lower mid-end hardware? which is what the new brute force AA approaches seem to fix on new high end cards.