Hi there, hope somebody knows a workaround, or if I should just report a bug.
In the game view in the included picture, please note the ugly diagonal stippled line in the left wall. This is the background colour showing through.
It looks as if a triangle that is nearly orthogonal to the camera is being culled prematurely. I can rule out some of the possible explanations:
There are no duplicate points, slightly apart. This mesh was generated by a script, and the triangles are in fact sharing the same points.
This is not a texture seam. I put the seam on the other side of the tunnel, where the same problem also appears by the way. )
The missing triangle is not being clipped by the viewing frustrum. HOWEVER one of its neighbours might be.
My theory is that some early backface culling is taking place based on the vertex normals.
These particular normals have been calculated by “Mesh.RecalculateNormals”.
I have also tried calling “Mesh.Optimize” which does not seem to affect the problem one way or another.
Unity does not do the backface culling by itself, it’s done in the hardware (and it only depends on positions on the screen; vertex normals don’t influence culling in any way). So I doubt it’s a culling glitch.
My wild guess: are you running on Intel GMA950 graphics card, and using pixel lights? For those cards (and a couple more on Windows) we have to “push” pixel lit geometry a bit further, to get rid of renering artifacts. The downside is that in some cases you get “double lighting” at grazing angles or intersecting geometry (but that is better than having surfaces flicker wildly everywhere - which would happen if we didn’t do the workaround).
I am not using pixel lights. I can’t.
And it is the background colour showing through, not weird lighting/texturing. I tried adjusting the background colour while paused, and the tear changes colour accordingly.
I am making a web-player demo of it. Ready in a few minutes.
I can see a couple (much less than in your shot) pixels that appear to be white (i.e. not background color), at grazing angles. Not sure if that’s lighting issue or mipmapping issue, or in fact some background showing through. That’s on MacBook Pro. Maybe you can send in the project folder that shows this via Report Bug.app?
It is pretty obvious here on my mac pro. Could it be a mipmapping or anisotropic filtering thing? I have had anisotropic textures turn funny colors before.
I don’t have any of those problems on my toshiba laptop, but I did notice that one of the squares has something going on with it, better to show than to try to exlain since I am not a graphics guy, and this is only on one triangle of the entire thing.
No problems at all on my G5 + X800. The thing is, I have seen that issue with one of my projects, in a similar situation. So I don’t know why it’s not showing up here. Here’s a shot…the blue dashed line is a polygon nearly edge-on to the camera, and yes that’s the sky showing through. If I move up or down slightly, the artifact disappears.
I don’t see your artifacts on my PowerBook/ATI 9700. However, on the same machine, I see exactly the same type of artifacts in my project. They’re kind of elusive and flicker on and off as I move around. In the attached image you can see an example of the artifacts as 3 dots above the word “hoe”. But sometimes I’ll clearly see a line of dots seemingly defining a polygon edge.
random dots like that might be because your polys aren’t joined in that area - to fix try either joining them in your 3D app or if you don’t want them joined overlapping one of them slightly (that was the problem with some of my meshes ; )
just to clarify for clarity’s sake so that it’s clear… (uhh… )
meshes should be welded or this type of artifact can appear. overlapping polys can work but also can open the door for other issues like flickering. welding is a better choice if you can.
carsten’s case though is a grazing angle issue (when a poly starts getting edge on to the camera). it’s easy to reproduce. just make a bumpy terrain. so far, the only way i’ve found to fix it is altering the geometry to play nice which can be a pita and is pretty restrictive. a better answer to this would be awesome (go aras!).
ps like eric’s example, i’m pretty sure it’s been background showing through for me. i don’t think it happens at say the edge of a cube. seems to show up most for me in terrains where angles aren’t that sharp. maybe a smoothing issue? i dunno but hth…
Ive had that"I can see the polgon edge" thing goin on a few times. Is it something that can be addressed using normal angle settings in the import settings window?
In a similar vein, last night my tutor told me Maya has a default normal angle of 30 degrees, and that Unity has a default angle of 60. That looks to be correct…?
AC
Is it something that can be addressed using normal angle settings in the import settings window?
i can’t say as i’ve specifically tested it but i don’t think so. i’ve never noticed a difference. i just mentioned the smoothing thing because it struck me as odd that it doesn’t seem to do this on objects with sharp angles. i’m sure it’s something totally different.
fwiw, i don’t think it’s related to the object being open or closed. pretty sure i’ve tried and gotten the same results on closed terrain meshes. been a while though. i’ll double check when i get a minute…
agreed - i should have been more specific - you will definitly get z-fighting if overlapped polys are not somewhat perpendicular (i’ve only used overlap on exact 90° intersections)
agreed too - flickering basically happens when coplanar polys overlap.
i should also that add tessellating can correct the grazing angle issue too. i’m a bit stuck in the mindset of “don’t add more polys!” nowadays poly count is becoming less of an issue. so maybe it’s just something to deal with when it happens. pretty much all geo’s like that.
I have updated my original webplayer example to pulsate the background colour, so you can tell the “hole in wall” problem apart from “z-buffer infighting” and “double lighting issue on GMA950”
The problem I have is “hole in wall”. There are no duplicate points, i.e. all points are welded by virtue of how the mesh is created.
There are also no coplanar polys, just one triangle that is edge-on to the camera.
I think I understand that this is a hardware bug. It is probably caused by differences in the numerical precision between
A) the calculation of the 2D determinant between two edges of the tri (which is used to decide backface culling)
B) the line rasterization (probably some variant of the Bresenham line algorithm(
I will probably have to make the problem less noticeable by using more polygons (so affected lines will not be so long)
On a MacBookPro I don’t see any background pixels. The only “anomaly” I see are almost white pixels at polygons that are at a very shallow angle. See the screenshot - at the bottom, between the near polygon’s top and the polygon that is more fogged. I think it just uses highest mipmap level there, which is some sort of bright color - so everything is ok.
That makes me think it’s a hardware culling issue. Culling is actually tricky - at least per D3D specification, the rasterizer is required to snap vertices to sub-pixel positions. And snapping can change the polygon’s orientation; so that means culling must be performed after this snapping in screen space (i.e. it can’t be performed in view space or post-perspective space). If the hardware gets it wrong, then there can be culling problems with very thin polygons.
)