Flickering ad boards

I have an issue with some ad boards on a track I am converting. They flicker a lot while the vehicle moves towards them. Here's a short movie to show what it looks like:
http://www.racehub.se/f1-2012/flickering-signs.avi

At first I thought it is because the sponsor object faces are located at the exact same location as the structure behind it, but that is not the case, they are offset by at least a centimeter, as this screenshot shows:
http://www.racehub.se/f1-2012/flickering-signs.jpg

The ad texture is a DXT5 for some reason, but has an all white alpha channel as far as I can see. Could this be the cause, or is there something else that can cause flickering like this?

 

Thanks Luc! No, the sponsor specific part is a separate .gmt object. I went through the textures and changed all DXT5 textures with a white alpha channel into DXT1, which took a couple of MB off the total .rfcmp size, and it actually took out some of the flickering in a few cases. Not sure why, but it did. Flickering is still present though, so I will try to merge the sponsor sign into the gantry structure and see if that helps. In this specific case there is also a non-rendered XSECTOR1 object in the middle of the gantry structure, but there are other similar gantry structures without a sector split, and they still flicker. Will report back with the progress.

 

I encounter similar problems as the ones you describe. However, I can tell that the texture itself can make the difference. I dont know exactly why, but several images are more likely to flicker than others. In my case the problem is very clear and annoying since it is our logo of Euskotracks which typically shows the biggest flickering. I will try to move this to dxt1 as you say to see the improvement.

Enviado desde mi GT-I9505 usando Tapatalk 2

 

Hi Jorgen.

The flickering you're getting have nothing to do with texture format. It is caused by the ClipPlanes parameter used in each car and those values are using a specific range to keep safe the cockpit view.

To get a confirmation you can try to switch between different car cams (onboard, swingman, TV, nose etc...) to see if the problem disappear for specific cams using different CPs.

There are few things you can try to get rid of the issue.

1) Don't use a single face sign above your structure. Extrude your sign by something around 2cm and cap the back.
2) Over exaggerate the distance between your sign mesh and the structure mesh to avoid Z issues when the car is driving in front of it.
3) Attach the sign mesh to the structure.

Of course, as Luc said, if your sign structure match the sign design - the best thing is to snap the sign face instead the metal cap on the structure. This solution works for sure as there are not multiple faces along a short distance and in the same projection...

Hope this helps....

 

Ok, more experiments. At first I just removed the sponsor logo object, and that showed that the gantry object itself does not flicker. Then I changed the gantry material from T1 to Specular Map T1. (which was due anyway because a plain T1 on a metal surface looks dull in the sunlight) Finally I copied the sponsor logo object faces into the gantry object and made the sponsor material use a Specular Map T1 shader too. Now it all looks great, but still flickers a lot when driving towards it.

Last step will be to use the sponsor logo material directly on the gantry object faces, and I suspect that will fix it. I still do not understand why the flickering occurs though. Is there a "layman's terms" explanation for why this happens?

EDIT: I typed when you posted Tuttle, thanks for the explanation! So, multiple faces close to each other and covering the same region is generally a bad idea? (at least in cases like this one)

 

Yes, even sometimes is necessary, as your case. The Z fighting is a common issue (solved for road arts with decals) caused by closed faces projected along the same axis. The ClipPlane is causing the issue when the value is very short, especially on very long straight where "overlapped" objects are rendered from a long distance.

 

Thanks a lot for the explanation Tuttle. I can confirm that after removing the separate ad board .gmt and applying the ad board material to the structure behind it (including some minor texture re-mapping) the flickering is gone.

 

Great!

 

I might not have understood but in my case the problem occurs only in one part of the texture where euskotracks logo is located. The rest of the bridgewall shows normal. In a different object with different texture the problem persists. I definitely think that some patterns are just more problematic. In this case the squared pattern would be the guilty of course. It looks like an antialiasing problem which as a result of patterns presents as flickering. I've prepared a short video to better explain.

 

Frames are interpolated on that video, so it's pretty difficult to see the problem as each frame is mixing more than 1 raw frame. If you post a static shot it's better..

Can you explain what I'm seeing on those viewports? (especially what are those overlapped faces).

 

BTW I see LOT of aliasing here, which is not a Z issue as the previous one. That bridge looks like a clean empty box based model (the Z issue is not expected here), so your problem looks more AA related and with straight and tight lines (like those green outlines) the aliasing is more evident in the distance (jaggies), when the engine is trying to render those lines inside the available Horizontal/Vertical resolution.

Things you've to check are, your AA setup first of all, the Mip bias of this texture (to aggressive negative values are killer for this situation) and even the quality of the DXT1 compression you're using. As a extreme solution you can try to increase the width of those green lines versus the white area - and/or re-think your UV pack to get more pixel resolution inside the texture.

 

I do also think it is more related to AA than to the alternating texture effect typical of white lines.
I will try to work with the texture itself with the tips you provided (thanks). WRT the video, sorry for the quality but youtube is a killer for that. In screenshot the problem cannot be observed since you as you said it is not an incorrectly rendered face problem. Next time I will use slow motion so that youtube's compression does not affect that much