Anti-Aliasing causes white outlines on objects

Since I upgraded to Unity 5, I have suffered from a problem where the objects in my game world have a white outline (both in the editor, and in build versions) - shown here:

After hours of trawling the internet, I came across the suggestion of disabling anti-aliasing within the Unity quality settings, and the ugly white lines disappeared entirely (see second screenshot):

Of course, this is not a good long-term solution, so I want to get to the bottom of it.Importantly, I have seen this on several occasions when I am playing games, where it is also most evident on trees. This would suggest to me that the fault may lie in my GPU/GPU drivers. All video drivers are fully up to date.

I would be extremely grateful for some feedback on this. Perhaps it is just a faulty GPU, but knowing this for sure would at least be a start.

Thanks!

 

Yes, I'm having this problem as well (Case 646115) bug reported in early beta

 

thanks for the reply, not sure how I managed to send you an empty project, sorry about that.
I cant seem to reproduce the issue I was having with the current version, perhaps something has changed and fixed it

 

I'm seeing this in Unity 5.0f4 as well. Disabling AA will fix the white artifacts.

 

Still seeing same issue on 5.01.

 

I uploaded a project attached to Case 688932

 

As far as I can tell its only tree creator trees that are not baked into the map. Speed trees don't seem to have it.

 

Nope.. Doesn't it happens only with trees. I've also some bushes that has the exactly same issue.. i guess it could be something related to a particular shader for the nature objects.

 

http://forum.unity3d.com/threads/ja...pecular-and-antialiasing.320984/#post-2086663

Thread with same problem and it actually seems to have a solution!

 

Hey guys I found out a temporary fix.
Try to change your graphics emulation to shader 2 or 3

 

I found this problem to also effect any model. With AA turned on, and the direction light (sun) set to be down (so basically facing up casting a shadow over everything) I was able to reproduce this error.



I am hoping this can be fixed as I'd prefer not to have to use a work around by turning AA off period. I also tried the work around provided and that didn't help.

 

This looks similar to an issue I reported a couple of years ago. Here's Unity 4:



And here's the bug entry in the issue tracker: http://issuetracker.unity3d.com/iss...px-white-border-between-object-and-its-shadow
The bug is still active although it's 2½ years old at this point so I'm not sure if it'll ever get looked at. Unity QA did confirm with me that they could reproduce it with my sample project though.

 

It could be something as simple as shadow problems, that those pixels that "break" are not picking up that they should be in shadow?

 

Bump on this issue. Persists with Unity 5.3.2p3

 

There are two issues at play here. The first one is straightforward but not easy to solve, and the second is more subtle and also not easy to solve.


The first one is screen space shadows. The main directional light shadows are rendered using the camera depth texture which is not anti-aliased. The result is badly aliased shadow edges even when anti-aliasing is enabled. I posted a work around here:
http://forum.unity3d.com/threads/fixing-screen-space-directional-shadows-and-anti-aliasing.379902/

The real fix is to not do the "deferred" directional shadow, which isn't something that can be disabled easily, and even when it is disabled also disables the use of shadow cascades. This is something Unity will have to change themselves to fix (and there's a good chance they will be).


The second issue is MSAA over interpolation. The solution is actually somewhat straightforward, just use centroid interpolation! (Okay, not quite straightforward.) The issue was best described in Valve's Advanced VR Rendering talk from last year and it goes into how MSAA works for why it's a problem. Short version is GPUs generally render the color for a pixel at the center of that pixel, but with MSAA the geometry being rendered might not actually cover the center of the pixel, it might only touch a corner. The result is the interpolated value for something like the surfaces normal is over interpolated and can point in a completely different direction than the surface actually faces.

Centroid sampling works by just adding _centroid to the output semantic, ex: float3 normal : TEXCOORD0_centroid;
Just doing this will get rid of several aliasing artifacts, but it will actually cause new aliasing artifacts on the interior of objects! This is because centroid sampling tries to keep the interpolated value within the triangle, but knows nothing of the mesh it's rendering beyond that so two triangles of the same mesh and material can start to have odd seams along those mid surface triangle edges. So now you need to be passing both the regular normal and the centroid normal and try to guess which one is correct. Valve's paper tests if the normal is facing away from the camera. I test if the normal has changed a significant amount between pixels (using fwidth). Neither are really "correct", but I found Valve's technique still resulted in a lot of aliasing when using something like Unity's Standard shader, Valve doesn't use a PBR shader so it probably works well enough for their purposes.

So far I haven't taken the time to implement the above on the standard shader. Probably wouldn't be too difficult, just a pain since the standard shader doesn't leave a lot of room for additional interpolants.