Anti-Aliasing does not function

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

view


https://drive.google.com/file/d/0B-kqm_hXFyf5SFVCbDN6UVZnbjg/view?usp=sharing

view


https://drive.google.com/file/d/0B-kqm_hXFyf5bk80clc4TDJxa2M/view?usp=sharing

view

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.
 
Easy solution:
1) load up the self land hangar module in star citizen.
2) walk around for 5 minutes
3) load up elite
4) realise that the AA could be a lot worse

(PS - this is not a dig at SC - I know it does not have AA implemented yet)
 
Hi

I have links for three more images of some sort of aliasing on shadows along edges which may look aliased from a distance - which happens on all shadow and illumination quality settings.

Again 2 images were too big to upload and it wouldn't accept them compressed either

https://drive.google.com/file/d/0B-kqm_hXFyf5VElPaU4wckJKMEU/view?usp=sharing

https://drive.google.com/file/d/0B-kqm_hXFyf5N3NNSWhVMnhYRTA/view?usp=sharing

https://drive.google.com/file/d/0B-kqm_hXFyf5MnI0clBxT3lDRkk/view?usp=sharing
 
Last edited:
Maiakaat: Thank you for the images, I see what you're getting at now. I think this is an issue with our shadow depth-bias (we've seen it much worse on lower shadow quality settings), and while it's not an antialiasing problem you're right that it could cause visual shimmering.
 
Hmm. I see it now too now it's been pointed out (thanks lol).

So, now the problem has been identified, how do we go about eliminating it Ben?
 
Hmm. I see it now too now it's been pointed out (thanks lol).

So, now the problem has been identified, how do we go about eliminating it Ben?

Until an official solution is released (and assuming your PC is powerful enough), you could try downsampling. It removes a lot of the issues people have been describing in this thread, and just generally makes everything run smoother - how much you can downsample will be determined by your PC, it's pretty much just trial and error until you find a good balance between quality and performance.
 
^^^ Basically everything Leak just said.

The only thing Leak doesn't mention there is that (a) hardware multisampling data can be used in deferred shading if you write the extra code, sadly if you want efficient GPU scheduling you probably want tile-based deferred rendering (like wot Frostbite does) and (b) some games temporally antialias their environments because their environments aren't constantly moving. I believe Black Flag doesn't apply temporal AA to its characters for exactly that reason but I may be wrong. (c) Whatever Maiakaat described may be an art bug rather than a tech limitation.

Oculus specific: There's a distortion applied after scene rendering to make things the right shape for Oculus, naturally this is going to magnify some areas of the screen and minify others, it doesn't surprise me that any aliasing we have would be more visible in the magnified areas. Downsampling is probably going to be the best solution to this, in hand-wavey terms one could imagine a multi-res system that only oversamples in areas that it knows will be enlarged, but I'm talking off the top of my head here.

Excuses. There are solutions. Use them.

Or better yet, think ahead a little bit and consider aliasing when deciding on deferred rendering. Aliasing is hardly the only downside too. In fact I find it difficult to understand why when faced with almost every downside imaginable, and amount of lights no game really needs in practice, why this approach is chosen again and again by apparantly smart people.

Maybe I come across a bit cross here, but I really consider deferred a plague and I'm happy when the fad will be over. I shudder every time I hear the word because it usually means the game will run poorly due to the crazy fillrate of a g-buffer, have poor light falloff, and be a soup of crawling pixels with maybe a blur filter over it if you're lucky. For me as a consumer I just can't see the benefit. And pretty much only Crysis 3 ever offered any kind of option to actually deal with the aliasing and not just gloss it over.

Especially as we move forward towards high resolutions and 3D, the extra horsepower required by deferred will be only more of a burden.
 
Last edited:
Excuses. There are solutions. Use them.

Or better yet, think ahead a little bit and consider aliasing when deciding on deferred rendering. Aliasing is hardly the only downside too. In fact I find it difficult to understand why when faced with almost every downside imaginable, and amount of lights no game really needs in practice, why this approach is chosen again and again by apparantly smart people.

That's a terrible attitude.
 
It's just a case of us pushing some biases up and down to find a better sweet spot. Too little you get this, too much and you get peter-panning (yes, it's actually called that).

Okey dokey, thanks for the communication :)

I'm running x2 DSR with 25% smoothness and I barely see it - mainly on pylons from distance and a few shimmies here and there. Nothing too major and certainly doesn't spoil the game for me at all.

Great to know you are looking at improving things still though, thankyou :)
 
Hey Ben Parry,

What version of SMAA is currently implemented in Elite Dangerous?
SMAA 1x, SMAA S2x, SMAA T2x, or SMAA 4x?

If it's currently SMAA 1x, could you please (pretty please!! with a cherry on top) upgrade the Implementation to SMAA T2x ?

I believe some of the aliasing some people are referring to would be the high frequency details. The subpixel antialiasing in SMAA T2x would solve the problems with high-frequency details.
Great Quality / Performance balance in this technique (SMAA T2x) aswell.
 
Last edited:
Why is the Anti Aliasing so bad?

It looks really bad on all options. I took some screenshots. To me it seems that only FXAA seems to be doing any AA but even then is still obvious. Is there any way I can improve this? I am running on a GTX 970.

OFF
eG1HYCQ.jpg


FXAA
CN6HnLB.jpg


MLAAx2
NKfng4H.jpg


MLAAx4
YMS8tha.jpg


SMAA
iK9e414.jpg


&

OFF
Q7w9PW0.jpg


FXAA
rxp2tNN.jpg


MLAAx2
4ZMjENs.jpg


MLAAx4
ZFsBXFL.jpg


SMAA
7bviGYJ.jpg
 
I guess it could be that what I thought were flipped vertices were another instance of shadow bias issues you describe, just perfectly lined up to look like a surface, it probably makes more sense.

It also seems to look pretty bad on all AMD settings on this card with SMAA (driver forced) barely making a recognisable difference compared with the above shots, so maybe there is some inherent driver issues with AMD on older cards too.

I guess I'll find out early this year when I upgrade

I wondered if you could use 64 bit struct stores housing two 32 bit values or one 64 bit value, and use the 64 bit value on the CPU side when really needed, and preferably the low or high 32bit value for different scenarios as needed, with a final option to extract a custom precision 32 bit value from the 64 bit value to meet less clear cases for 32 bit values required by SIMD/AVX and GPU FP performance limitations (I know its a bit more complicated than that)

I have a 16 CPU workstation, and it and the RAM is barely used (about 5-10% CPU at peak), so I think there is scope for loading more work onto the client CPU where higher settings are used. I understand DirectX11 has thread performance issues with one thread being disproportionately used.

Also given the scale of space I wondered whether some sort of curve/path-based smoothing could help with any other precision problems, if not done already, through some sort of recursive precision on a motion curve. These are just some vague ideas.
 
Last edited:
It looks really bad on all options. I took some screenshots. To me it seems that only FXAA seems to be doing any AA but even then is still obvious. Is there any way I can improve this? I am running on a GTX 970.

Use DSR 4.00x via your driver control panel, then use SweetFX to smooth over what the downscaling doesn't get. The AA is really is rubbish in this game, so that's about as good as you're going to get. What's Transparency AA? No, I don't like that, I prefer my modern game running on a PC to look like textures on a Playstation version of Textures®.

I don't think that means what you think it means


SweetFX bro.
 
Last edited:
The difference at all these screenshots is clearly visible.
I'm sorry, but playing the game, which mean a *moving* image, still looks horrible. Screenshots might look a bit better, but as soon as there's movement, the aliasing and shimmering are apparent regardless of which setting you use.

This game needs MSAA, end of story :-/ And it's not even a console port. It's a PC game, there should be MSAA in it.
 
Use DSR 4.00x via your driver control panel, then use SweetFX to smooth over what the downscaling doesn't get.
If you enjoy the framerate turning into a stutter-fest, then yeah, do that :p

DSR 4x is a stutter-fest for me, and I have a powerful PC (GTX 780, 4.2GHz quad core i5.)

Also, for some reason, the game's engine doesn't use triple buffering when vsync is on. That one I can't comprehend. It makes the game run at 30FPS just because you fall under 60FPS. Fortunately you can fix that yourself with third-party tweak tools like Radeon Pro or D3DOverrider. But why they don't use TB on their own is a mystery. In general their engine seems to have big problems. No proper AA and extreme micro-stutter at random even in the middle of nowhere with nothing but the skybox visible.

There's still a lot of work required to make this game look and run well. I just can't shake the feeling that they released it in a very unfinished state, both from a technical as well as a gameplay perspective.
 
Last edited:
Yeah, I've noticed the aliasing on stations seems worse than it should be too. It's not terrible, but it doesn't seem to be working correctly either. I have a 970GTX and I've found the best looking solution is with DSR up to 4K and downsampling, but my framerates suffer then so I keep the res at 1080p and instead use SMAA in game and force FXAA with Nvidia Inspector. This seems to give me the best results so far, although I do want to experiment some more with Inspector settings.

Either way, it's not lessening the fun I'm having with the game, it's just annoying me in the screenshots I'm taking, lol!
 
Back
Top Bottom