xLODGen - Terrain LOD beta 128 for FNV, FO3, FO4, FO4VR, TES5, SSE, TES5VR, ENDERAL, ENDERALSE

[ikonomov]

sheson, if you would, can you comment on my previous post.  What would be your recommendation to use for LOD8 and LOD16?

Edited April 3, 2021 by ikonomov

[ikonomov]

Actually I'm still seeing flickering around the edges between water and land at a distance with 550 for Optimize Unseen for LOD8 and LOD16.  When I tried On and Off it was more pronounced covering larger areas.  I'm observing this by looking at the shallow water area north of Morthal.  I'm standing near the Lord Stone in the mountain.  Any suggestions to minimize this?

Thank you

Edit: I noticed some z-fighting in other places like around rocks.  Prior to using xLODGen for terrain textures I was using only Terrain LOD Redone and I don't remember seeing much of z-fighting then.  Do you have any insight about why there seems to be more with xLODGen?

Edited April 3, 2021 by ikonomov

[sheson]

4 hours ago, ikonomov said:

This is probably expected behavior, but in the shallow waters north of Morthal I noticed some z-fighting with fairly large areas flickering.  It is only happening at a distance, so it must be either in LOD8 or LOD16.  Having the Optimize Unseen to On and Off results in the same behavior from what I could see, but with 550 it disappeared.  I have uLargeRefLODGridSize=11 (Ultra) and with 550 if there is some shifting going on when I get closer into LOD4 (Optimize Unseen Off) it is too far for me to see it.  So for some people 550 might be the preferred setting to use for LOD8 and LOD16 as well as the LOD32 map meshes.

Obviously the large reference system has no effect on terrain or terrain LOD.

Test and a find a different values for LOD level 8 and 16 that work best for the load order and the setup, then let us know your results. However, you can not expect z-fighting between terrain and LOD water to magically disappear, only be less pronounced.

1 hour ago, ikonomov said:

Actually I'm still seeing flickering around the edges between water and land at a distance with 550 for Optimize Unseen for LOD8 and LOD16.  When I tried On and Off it was more pronounced covering larger areas.  I'm observing this by looking at the shallow water area north of Morthal.  I'm standing near the Lord Stone in the mountain.  Any suggestions to minimize this?

Thank you

Edit: I noticed some z-fighting in other places like around rocks.  Prior to using xLODGen for terrain textures I was using only Terrain LOD Redone and I don't remember seeing much of z-fighting then.  Do you have any insight about why there seems to be more with xLODGen?

Obviously, the used LOD generator does not change how the engine works or why things z-fighting. Lower quality terrain LOD meshes with larger triangles that might have less intersections with other objects.

[ikonomov]

9 hours ago, sheson said:

Obviously the large reference system has no effect on terrain or terrain LOD.

Test and a find a different values for LOD level 8 and 16 that work best for the load order and the setup, then let us know your results. However, you can not expect z-fighting between terrain and LOD water to magically disappear, only be less pronounced.

Obviously, the used LOD generator does not change how the engine works or why things z-fighting. Lower quality terrain LOD meshes with larger triangles that might have less intersections with other objects.

Thank you for the reply.  Lots of things must be obvious to you, but probably less obvious for the rest of us.  Sorry for the trivial questions.

If some z-fighting is to be expected then I think the 550 for all LOD8, LOD16 and LOD32 seems to work fairly well.  There is still a little bit of flickering, but the water line looks to be almost intact and I see little change to it going into LOD4.  It must be a good balance I think.

There is one big rock wall that I was looking at which was exhibiting a huge amount of z-fighting.  I looked at it closer and I don't think the problem is with the LODs.  When I'm right next to it I can clearly see a landscape mesh and a flat rock mesh overlapping and fighting with each other as they are mostly on the same plane.  The two meshes slowly shift from one to the other as I'm walking right next to it.  The only way this wouldn't have shown in the Terrain LOD redone is if he edited that mesh manually, which I don't think he did, so it must be that I simply didn't notice it before.

[sheson]

1 hour ago, ikonomov said:

Thank you for the reply.  Lots of things must be obvious to you, but probably less obvious for the rest of us.  Sorry for the trivial questions.

If some z-fighting is to be expected then I think the 550 for all LOD8, LOD16 and LOD32 seems to work fairly well.  There is still a little bit of flickering, but the water line looks to be almost intact and I see little change to it going into LOD4.  It must be a good balance I think.

There is one big rock wall that I was looking at which was exhibiting a huge amount of z-fighting.  I looked at it closer and I don't think the problem is with the LODs.  When I'm right next to it I can clearly see a landscape mesh and a flat rock mesh overlapping and fighting with each other as they are mostly on the same plane.  The two meshes slowly shift from one to the other as I'm walking right next to it.  The only way this wouldn't have shown in the Terrain LOD redone is if he edited that mesh manually, which I don't think he did, so it must be that I simply didn't notice it before.

Terrain and terrain LOD is the ground you walk on. Reference records in plugins place objects defined by base records. Reference in loaded cells can typically be clicked on and have form ids.  Objects have their LOD done in object LOD.  Large references are  references that also show outside the loaded cells in the LOD area a bit further before they switch to LOD. If references have a tree base records or a  static base record flagged as having tree LOD,  they are part of billboard tree LOD. Most of these things are well documented in the CK wikis and other guides for the may games that xLODGen supports.

If you believe a problem has to do with LOD, turn off LOD with tll in console to see if the problem goes away. It always turns off all LOD.

However, typically a rock wall is an reference and if that flickers with LOD, the LOD is typically object LOD. If that happens just outside the loaded cells, it is large reference bugs.

If this happens inside the load cells, that it is stuck object LOD after fast travel, that can be fixed by not using ultra settings or by changing the fBlockLevel0Distance a bit. From 60000 to 57000 for example.

 

[ikonomov]

2 hours ago, sheson said:

Terrain and terrain LOD is the ground you walk on. Reference records in plugins place objects defined by base records. Reference in loaded cells can typically be clicked on and have form ids.  Objects have their LOD done in object LOD.  Large references are  references that also show outside the loaded cells in the LOD area a bit further before they switch to LOD. If references have a tree base records or a  static base record flagged as having tree LOD,  they are part of billboard tree LOD. Most of these things are well documented in the CK wikis and other guides for the may games that xLODGen supports.

If you believe a problem has to do with LOD, turn off LOD with tll in console to see if the problem goes away. It always turns off all LOD.

However, typically a rock wall is an reference and if that flickers with LOD, the LOD is typically object LOD. If that happens just outside the loaded cells, it is large reference bugs.

If this happens inside the load cells, that it is stuck object LOD after fast travel, that can be fixed by not using ultra settings or by changing the fBlockLevel0Distance a bit. From 60000 to 57000 for example.

 

It was a snow covered area with loose/smaller rocks surrounded by some large rocks.  Using the tll command revealed the area to be part of a large reference.  When the cell fully loads there appears to be another mesh of snow cover on top of the loose/smaller rock area that's partly covering it.  It doesn't seem to be related to fast traveling.  Once the LOD is turned off the flickering disappears.  So I guess the problem is from the LODs, but looking closely at those two meshes they are almost on the same plane, next to each other overlapping, it seems reasonable to see this especially if some z-fighting is to be expected as with the water line.

Edited April 3, 2021 by ikonomov

[sheson]

13 minutes ago, ikonomov said:

It was a snow covered area with loose/smaller rocks surrounded by some large rocks.  Using the tll command revealed the area to be part of a large reference.  When the cell fully loads there appears to be another mesh of snow cover on top of the loose/smaller rock area that's partly covering it.  It doesn't seem to be related to fast traveling.  Once the LOD is turned off the flickering disappears.  So I guess the problem is from the LODs, but looking closely at those two meshes they are almost on the same plane, next to each other overlapping, it seems reasonable to see this especially if some z-fighting is to be expected as with the water line.

Turn off large references to verify if it is a large reference bug.

If it is the case, check the DynDOLOD log for the lines that tell which references and plugins are causing them.

[ikonomov]

12 minutes ago, sheson said:

Turn off large references in the INI to verify if it is a large reference bug.

I changed uLargeRefLODGridSize to 0, and the flickering seems gone.  Did a number of tests moving closer and far away and I don't see it.

[sheson]

9 minutes ago, ikonomov said:

I changed uLargeRefLODGridSize to 0, and the flickering seems gone.  Did a number of tests moving closer and far away and I don't see it.

There you go, the usual well known engine bugs caused by plugins and that have nothing to do with LOD generation.

[ikonomov]

15 minutes ago, sheson said:

There you go, the usual well known engine bugs caused by plugins and that have nothing to do with LOD generation.

Yep.  Caused by plugins, does that mean that it's caused by other mods I'm using?

[z929669]

10 hours ago, ikonomov said:

Thank you for the reply.  Lots of things must be obvious to you, but probably less obvious for the rest of us.  Sorry for the trivial questions.

If some z-fighting is to be expected then I think the 550 for all LOD8, LOD16 and LOD32 seems to work fairly well.  There is still a little bit of flickering, but the water line looks to be almost intact and I see little change to it going into LOD4.  It must be a good balance I think.

There is one big rock wall that I was looking at which was exhibiting a huge amount of z-fighting.  I looked at it closer and I don't think the problem is with the LODs.  When I'm right next to it I can clearly see a landscape mesh and a flat rock mesh overlapping and fighting with each other as they are mostly on the same plane.  The two meshes slowly shift from one to the other as I'm walking right next to it.  The only way this wouldn't have shown in the Terrain LOD redone is if he edited that mesh manually, which I don't think he did, so it must be that I simply didn't notice it before.

We have tested this to reduce z-figting to a minimum, and most recently Tech found the settings we posted on the 1.0.0 guide for LOD 4 > 8 > 16 > 32:

500 > 525 > 625 > 525 (can probably be off here though)

I personally use mips and steepness at LOD 4, since I think sheson mentioned mips are usedin LOD 4 fade somewhere around here. I have yet to test if this change is apparent and 'good'

[sheson]

9 hours ago, ikonomov said:

Yep.  Caused by plugins, does that mean that it's caused by other mods I'm using?

The DynDOLOD log lists which references and plugins trigger the large reference bugs.

[ikonomov]

21 hours ago, z929669 said:

We have tested this to reduce z-figting to a minimum, and most recently Tech found the settings we posted on the 1.0.0 guide for LOD 4 > 8 > 16 > 32:

500 > 525 > 625 > 525 (can probably be off here though)

I personally use mips and steepness at LOD 4, since I think sheson mentioned mips are usedin LOD 4 fade somewhere around here. I have yet to test if this change is apparent and 'good'

Thank you for testing and posting these numbers.  They are quite close to 550, but maybe it does make a difference.  I'm especially interested to test having it for LOD4, which for me is currently off.

The mipmaps and steepness shouldn't matter for z-fighting I think, since it's a mesh problem not textures.

[z929669]

19 minutes ago, ikonomov said:

The mipmaps and steepness shouldn't matter for z-fighting I think, since it's a mesh problem not textures.

True. I just mentioned it, because the settings I linked don't have that and to spur any comments as to the legitimacy of doing so.

[ikonomov]

2 hours ago, z929669 said:

True. I just mentioned it, because the settings I linked don't have that and to spur any comments as to the legitimacy of doing so.

sneaky

I am curious myself.  Maybe for very large texture sizes it could make some difference for performance.  I'm using 1024 diffuse and 512 normal texture size for LOD4 and 512/256 for 8/16/32.  I didn't really do much testing to compare.  I'm using SSE Display Tweaks with a Gsync monitor, if we know for certain that those mipmaps are used for LOD4 somehow we could do some testing to see if it can actually make a difference to the framerate.  My guess is that theoretically it could, but in practice I think all the other LOD textures being loaded are eating a much larger chunk of the framerate than the terrain textures.