Any global fix to flickering textures?

Discussion in 'General Discussion' started by Marc Collins, Apr 7, 2015.

  1. Marc Collins

    Marc Collins Registered

    Joined:
    Jan 11, 2012
    Messages:
    3,159
    Likes Received:
    162
    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)?
     
  2. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
    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).
     
  3. Marc Collins

    Marc Collins Registered

    Joined:
    Jan 11, 2012
    Messages:
    3,159
    Likes Received:
    162
    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?
     
  4. TechAde

    TechAde Registered

    Joined:
    Oct 13, 2010
    Messages:
    606
    Likes Received:
    38
    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
     
  5. Marc Collins

    Marc Collins Registered

    Joined:
    Jan 11, 2012
    Messages:
    3,159
    Likes Received:
    162
    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.
     
  6. stonec

    stonec Registered

    Joined:
    Jun 19, 2012
    Messages:
    3,399
    Likes Received:
    1,489
    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.

     
  7. wgeuze

    wgeuze Registered

    Joined:
    Oct 1, 2012
    Messages:
    1,608
    Likes Received:
    63
    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.

    [​IMG]
     
  8. stonec

    stonec Registered

    Joined:
    Jun 19, 2012
    Messages:
    3,399
    Likes Received:
    1,489
    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.
     

Share This Page