I just can't believe that after experiencing this since 2005 in rF1 that simple changes to cam files cure the problem. As mentioned, even ISI tracks have the problem (though usually very minor) and we don't see it in competitor's products. On the other hand, as I mentioned initially, changing cars (and cam file, by definition) can change the effect, so it is influenced by the cam file. I would like to think that a solution could be created to always show the closest plane to the viewer when the too-close and conflicting objects are past a certain distance from the viewer and therefore any detail necessary to have the objects so close together in the first place is deemed irrelevant (because it couldn't be seen by a human eye at that distance anyway). Is this too simple? Do we really need to painstakingly edit 100+ tracks (of which at least 70% have already been orphaned)?
What's not to believe? When we see z-fighting what we're actually seeing is z-buffer precision issues. There are two basic solutions: 1) Improve the precision of the z-buffer in the areas that matter by pushing the near clip plane further from the camera. In rFactor1 & 2 the near clip plane is defined in the car's cam file. 2) Move the objects that are z-fighting further apart. Solution 1 entails changing a few numbers in a text file, solution 2 entails changing the 3D geometry and re-exporting to GMT. So what's wrong with solution 1? It's like the negative bias thing, people have been doing it the "wrong" way for years (i.e. setting the near clip plane too close in the car cam files). That doesn't mean the "right" way isn't out there (and has been since day dot).
Wow, if it is just editing cam files then it truly is sad that we've been dealing with this for 10 years now. I take it there is not a universal "right answer" cam text file entry(ies) that work, because if so, we wouldn't see this problem in ISI tracks (and ISI cars like the NSX rear bumper) while using ISI cars? Two readily available and replicable examples of the flashing are South Shore advertisements and ISI Belgium at night--the lights in the houses. I will check later if every single car and view has the issue, or just a sub-set. Is it as simple as finding one cam (if it exists) that doesn't produce the flashing and using those values in all the other cams?
The problem with going too high is you start clipping out the steering wheel, dash etc., anything closer to the camera than the near clip plane. Some of the examples you mention may well need a geometry tweak as well as optimised clip planes. There isn't really a one size fits all solution when you consider the flexibility of the system. Added: Things like car parts switching lods at distance has nothing to do with clip planes, if that's what the car you mention does. Sent from my SM-G900F using Tapatalk
I do know that the vast majority of the problems I see are with distant objects. If you drive right up to them, or sometimes just get closer than 50 virtual metres, the flashing will stop. That's why the logarithmic thing sounded like a neat option to me. It might work for a large chunk of the problem areas. Oh well, maybe someone from ISI will clarify what could be done, what they plan to do and what they expect others to do. Thanks to all who chimed-in with information.
The camera preset defaults need to change then. LRP (which is at version 2.0) has flickering trees on about every second trackside camera and 2 or 3 places from cockpit as well. Watch fullscreen to see it properly. If ISI trackbuilders can't with reasonable effort tune the cameras right to avoid this, modders can't either.
That particular problem, if those are billboard trees probably doesn't have anything to do with the camera settings. What is probably happening is the billboards themselves are ending up being rendered on almost exactly the same plane because of their behavior, rotating/facing towards the main active camera. Here there are 3 sets of trees (top view). I've only copied the left set two times and only rotated the billboards. You can check the rotation because of the smaller straight line down the middle of the billboards. The middle set has been rotated a bit, not a problem. However the far right one is going to cause an issue. You can already see it happening top down, this is so close on top of each other, stuff is likely to go wrong. Moving one of the two trees so they are less prone to overlap is a quick and easy fix.
Right, that makes sense to why of all ISI tracks only LRP has these flickering trees, as the trees are placed very close to each other on this track.