home
Skyrim
Terms of Service | Privacy Policy
Copyright © 2024 Robin Scott. All rights reserved.

Skyrim Tweaks and Fixes 1: Mountain flicker and Z-fighting

  • Comment
More articles

27 comments

Comments locked

A moderator has closed this comment topic for the time being
  1. Lordofcats677
    Lordofcats677
    • member
    • 1 kudos
    This didn't change anything for me no matter how much I tweaked it, it just got worse, I wonder if anyone has questioned any developers on this at all, it would be nice if they just made a patch to remove all the shadows from the mountains.
  2. BimboBanana
    BimboBanana
    • member
    • 12 kudos


    Superb Guide as always ;-) But i still have some flickering with this Settings.

    To cut to the chase - the zfighting flickering annoys me from the beginning of the Game, so i read a hundreds of Sites and Thread´s to fight against it.
    And after many hours of testing, i finally found some Values that worked pretty fine for me - no flickering on Mountains anymore.

    I like to share this Values with you, so i post it here....

    [TerrainManager]
    fTreeLoadDistance=125000.0000
    fBlockMaximumDistance=80000.0000
    fBlockLevel1Distance=80000.0000
    fBlockLevel0Distance=80000.0000
    fSplitDistanceMult=4.5000
    bShowLODInEditor=0

    Hope that will help some of you, like it does for me ;-)


     
    I've tried quite a few ini tweaks myself as this z-fighting issue was just awful. With all those other solutions I still experienced it. However, obeck22's solution works for me. I've absolutely no problem with less details in the far away mountains as the focus per se is my character's direct surroundings, so this tweak is definitely my cup of tea. Thanks for all your hard work on this issue, and special thanks to obeck22. :-)
  3. colt2010
    colt2010
    • member
    • 0 kudos
    Just wanted to let u all know.
     As suggested in this topic by setting my game to ultra settings seems to have stopped the flickering mountains completely. Thanku all.........
     
     
    Specs:
    Win 7 Home Premium (Service Pack 1)
    64 Bit Operating System
    AMD Phenom  II X4 955 Black Edition Running at 3.8 GHZ
    8.0 GB Ram
    GTX 760 At Factory Settings (No Overclock)
    Happy Gaming 2 u all.
     
     
     
     
     
     
  4. 3AMt
    3AMt
    • member
    • 125 kudos
    I had it fixed once, with high mountain details. Now Im trieing to find the stting I had, all fixes I found now lead to low poly meshes <img class=">
  5. MrZoner
    MrZoner
    • premium
    • 0 kudos
    Z-fighting can be caused by a few things. All of them are related to 32 bit floating point precision. Z-fighting boils down to two triangles that when converted to pixels and depth values, have identical or similar depth values. The 'fighting' occurs because the vertices of two triangles are being snapped to different positions at different rates, which makes them them wobble. Once you have two wobbling triangles overlapping, they take turns being in front, and thus z-fighting.

    So first a primer on floating point numbers:

    Floating point numbers have an exponential distribution.

    32 bits = 4294967296 maximum possible values. floats have a few less, because they need to encode NaN (not a number) and INF(infinity).
    1 sign bit, not relevant to z-buffers
    8 bits are used for the exponent, half are for negative exponents to make numbers between 0..1 and the other half are for values from 1..max float (1e38 or so, a huge number)
    23 bits are used for the mantissa.


    This all results in a few really non-intuitive properties:


    • There are 255 ranges of values (from the exponent).
    • Each range has 16777215 values within it (from the mantissa).
    • The steps between values within a range is linear. As the exponent gets larger, each range doubled in size (with the same number of steps within it).
    • The range 0..1 has as many discrete values as 1..1e38
    • The range 0.5..1 has as many as 1..2 which also has many as 2..4 etc
    • When value stored is larger than 8388608, there are no more decimal points left, you are working with integers!
    • Values larger than 16777216 increment by 2, etc
    • Values larger than 33554432 increment by 4, etc
    • When you add or subtract a very very small number to a very large number, the small number can have no affect on the outcome (data loss!). 33554432 + 0.05 = 33554432; etc



    Ok so with this knowledge it can help explain the various types of precision loss that can occur with a polygonal mesh:


    • Game worlds tend to use their own coordinate system. If the game engine uses 'world coordinates' for meshes sent to the GPU, you can get precision loss when working on verts in this space, before transforming them. The meshes get temporarily converted from the model coordinate system (where each model is at 0,0,0), to the world coordinate system (some huge number), then transformed again to be relative to the camera. Merely having the mesh's vertices exist at their world space values can cause them to get rounded to some horrificly inaccurate value.This kind of problem is fixed by making the engine transform the mesh directly from the model coordinate system to a view-relative coordinate system, and only making world space verts available for shaders that need to operate on them in some way.
    • The near/far planes can be misconfigured. The distributions of values in z-buffer is also non-linear, and heavily favors nearby objects. The ratio of the near and far planes determines the distribution, so pulling in the far plane or pushing out the near plane will increase precision. Each time you cut the far/near ratio in half it effectively doubles the precision.This is why games tune their near plane to be as far out from the camera is possible but not far enough you cause it to clip through walls in buildings.Some games use an 'infinite projection' (most unreal engine 3 games for instance) which makes the near plane the only value you can tune as well.
    • The game might not be using inverted z-buffers. The vast majority of available values in floating point lie near zero.The projection transform the vertex shaders use generates values that are much closer to 1.0.In a game like skyrim, if you are standing directly in front of a wall, the z-values are probably already at something like 0.6 or higher. Anything far away are all fighting for values like 0.99998 and 0.99997, which causes z-fighting due to all the polygons getting rounded to nearly identical z values. Because each vertex snaps at a different rate, the mesh wobbles, so half the triangle is 0.99998 one frame and 0.99997 the next and back again. The fix for this is to invert the z-buffer so that 0 is far and 1 is near.This is something that might be fixable with a D3D9 dll injection/wrapper like ENB, however finding and patching the projection transforms that are sent to all the shaders might be difficult.This kind of problem can also improved shadowmap, as a lot of shadowmap aliasing is caused by reading less-accurate depth values from the z-buffers the shadows are built from.


    The simplest 'non programming' fix is often to remove the overlapping polygons (merge the meshes, get rid of as much overlapping geometry as possible).

    Z-buffers are 24 bit (no sign bit, possibly fewer exponent bits since they don't have to store positive exponents, and the exact nature of each hardware configuration is a guarded secret). They behave the same otherwise as 32 bit, but fewer bits means its easier to see these kinds of precision problems.
  6. Odysseus
    Odysseus
    • member
    • 13 kudos
    Wow Great idea! Now I'll just come here for fixes instead of googling Everything lol. An this Mt flickering fix is a Must have, Thanks!
  7. DavidKNS
    DavidKNS
    • supporter
    • 0 kudos
    Thanks, good video
  8. EredarTheAncientDemon
    EredarTheAncientDemon
    • BANNED
    • 0 kudos
    CAn you help me fix this?I am stucking in reading the Elder Scroll.
    I can't walk around and finish the Elder Knownledge
  9. skwareballz
    skwareballz
    • member
    • 3 kudos
    The people that frequent the STEP forums and that edit the STEP Wiki are an awesome bunch. The Compiler has only made his guide better and better, and it's probably the best you can get Skyrim looking unless you spend hundreds of hours testing all the mods yourself, but why do that when the compiler has done it for you.
  10. faeriexdecay
    faeriexdecay
    • premium
    • 170 kudos
    Excellent idea for a video series. Can't wait for more! Thanks again, Gopher.