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

[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.

[sheson]

1 hour ago, ikonomov said:

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.

In Skyrim terrain LOD does not seem to use any mipmaps. Only the fade in the loaded cells.

[z929669]

... so then it sounds like the mips are used by the full textures in the span of the fade transition rather than in LOD4. Here is a vid of transition on terrain, but it's probably grass object and not terrain I'm thinking. Very subtle. See center screen.

 

[ikonomov]

I wanted to get A Quality World Map mod working with xLODGen and DynDOLOD, but I can't figure out why this one area is showing incorrectly.  I have extracted the textures from the mod's bsa, loaded them after the xLODGen textures and also loaded the plugin after DynDOLOD.  Everything looks good except this one square.  Should I just re-run xLODGen with nothing generated for LOD32?

Thank you

EDIT: Hah, only problem is that I can't disable generation of meshes and textures only for LOD32, it disables it for all of them.

Edited April 5, 2021 by ikonomov

[sheson]

1 hour ago, ikonomov said:

I wanted to get A Quality World Map mod working with xLODGen and DynDOLOD, but I can't figure out why this one area is showing incorrectly.  I have extracted the textures from the mod's bsa, loaded them after the xLODGen textures and also loaded the plugin after DynDOLOD.  Everything looks good except this one square.  Should I just re-run xLODGen with nothing generated for LOD32?

Thank you

EDIT: Hah, only problem is that I can't disable generation of meshes and textures only for LOD32, it disables it for all of them.

There is no need to delete files that are being overwritten by mods loading with higher priority as they are being replaced already. Whatever mod supplies the file(s) last wins. Overwritten files do not have any affect whatsoever.

If you do not want to use LOD level 32 files from xLODGen or other mods, simply delete them from the output/mod folder. There is no need to extract files from a BSA then.

A Quality worldmap has no conflicts with DynDOLOD, however if its plugin makes changes to the worldspace records it needs to be loaded last when generating LOD, so that records are copied into DynDOLOD plugins with all changes carrying forward.

Regarding the problem on the map I suggest to test with default INI settings, especially the uLockedObject and uLockedTerrain.
It is unclear from the screenshot if the problem is terrain meshes or textures. is the white square see through (missing mesh) or solid (white texture)?

[ikonomov]

58 minutes ago, sheson said:

There is no need to delete files that are being overwritten by mods loading with higher priority as they are being replaced already. Whatever mod supplies the file(s) last wins. Overwritten files do not have any affect whatsoever.

If you do not want to use LOD level 32 files from xLODGen or other mods, simply delete them from the output/mod folder. There is no need to extract files from a BSA then.

A Quality worldmap has no conflicts with DynDOLOD, however if its plugin makes changes to the worldspace records it needs to be loaded last when generating LOD, so that records are copied into DynDOLOD plugins with all changes carrying forward.

Regarding the problem on the map I suggest to test with default INI settings, especially the uLockedObject and uLockedTerrain.
It is unclear from the screenshot if the problem is terrain meshes or textures. is the white square see through (missing mesh) or solid (white texture)?

I just checked, the only change A Quality World Map makes inside the .esp is an edit to the WorldMapWeather, so the plugin place shouldn't matter.

The white square is a solid white.  A Quality World Map only has textures, 24 for tamriel.  I wrote to the author asking if he can upload a version with loose files, rather than BSA archive, to make it easier to manage the textures placement in the load order with a mod manager, but no reply yet.

If LOD32 meshes and textures can simply be deleted from the generated xLODGen files, I wonder if it would be possible to allow LOD32 to be independent of the other textures/meshes when generating.  I understand it wouldn't make sense to generate meshes or textures for LOD4, LOD8 and LOD16 separately, but if LOD32 is used only for the map I think it could be useful to have the option to choose, if needed for such mods.

In case somebody else is using xLODGen with A Quality World Map, rather than going into each mesh and texture folder a little easier to manually search and delete all the LOD32 files after xLODGen generation:

*World.32*
*Blackreach.32*
*DLC01FalmerValley.32*
*DLC01SoulCairn.32*
*Sovngarde.32*
*Tamriel.32*

[sheson]

21 minutes ago, ikonomov said:

I just checked, the only change A Quality World Map makes inside the .esp is an edit to the WorldMapWeather, so the plugin place shouldn't matter.

The white square is a solid white.  A Quality World Map only has textures, 24 for tamriel.  I wrote to the author asking if he can upload a version with loose files, rather than BSA archive, to make it easier to manage the textures placement in the load order with a mod manager, but no reply yet.

If LOD32 meshes and textures can simply be deleted from the generated xLODGen files, I wonder if it would be possible to allow LOD32 to be independent of the other textures/meshes when generating.  I understand it wouldn't make sense to generate meshes or textures for LOD4, LOD8 and LOD16 separately, but if LOD32 is used only for the map I think it could be useful to have the option to choose, if needed for such mods.

In case somebody else is using xLODGen with A Quality World Map, rather than going into each mesh and texture folder a little easier to manually search and delete all the LOD32 files after xLODGen generation:

*World.32*
*Blackreach.32*
*DLC01FalmerValley.32*
*DLC01SoulCairn.32*
*Sovngarde.32*
*Tamriel.32*

Temporarily disable the terrain LOD texture so it falls back to vanilla for that area to see if the problem goes away. If that doesn't change anything then the terrain LOD mesh. 

You can choose which LOD levels to generate by using the specific chunk drop down. However, that is one LOD level at a time.

[ikonomov]

53 minutes ago, sheson said:

Temporarily disable the terrain LOD texture so it falls back to vanilla for that area to see if the problem goes away. If that doesn't change anything then the terrain LOD mesh. 

You can choose which LOD levels to generate by using the specific chunk drop down. However, that is one LOD level at a time.

I've already deleted the old xlodgen and dyndolod files and created new ones without LOD32.  To test I disabled all new xlodgen and dyndolod files and generated just textures and meshes for LOD32 with xlodgen using the chunk drop down.  Then I installed extracted texture files from the map mod.  The square does not show anymore and everything looks normal.  I have absolutely no idea what might have caused it before, but maybe it was human error on my part somehow.  If you think necessary, I can re-generate everything including dyndolod the way I did for the old files to make sure.

The chunk drop down is great, it didn't occur to me that it can be used for a whole LOD level and not just for a specific area by leaving the x and y empty.  Running it 3 times is no issue, but if possible and easy to do it would be great if instead of 'empty/4/8/16/32' we can have 'all/4+8+16/4/8/16/32' in the drop down menu.

[sheson]

1 hour ago, ikonomov said:

I've already deleted the old xlodgen and dyndolod files and created new ones without LOD32.  To test I disabled all new xlodgen and dyndolod files and generated just textures and meshes for LOD32 with xlodgen using the chunk drop down.  Then I installed extracted texture files from the map mod.  The square does not show anymore and everything looks normal.  I have absolutely no idea what might have caused it before, but maybe it was human error on my part somehow.  If you think necessary, I can re-generate everything including dyndolod the way I did for the old files to make sure.

The chunk drop down is great, it didn't occur to me that it can be used for a whole LOD level and not just for a specific area by leaving the x and y empty.  Running it 3 times is no issue, but if possible and easy to do it would be great if instead of 'empty/4/8/16/32' we can have 'all/4+8+16/4/8/16/32' in the drop down menu.

Don't worry about it if works now.