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

[kleshas]

Installed latest STEP, and am running the xLODGen.  Tried a few times, and nearly every time it fails with a message "Failure to add alpha layer on .." and the texture varies here on each run.

Also, I notice that the "bake normal-maps" checkmark setting on LOD32 makes all the other LODs also be checked (the guide says that it shouldn't be checked for LOD4, 8, 16).  If you disable it on LOD4, it disables for all other LODs too.

 

bugreport.txt LODGen_log.txt SSELODGen_log.txt

Edited August 27, 2024 by kleshas
better logs

[z929669]

1 hour ago, kleshas said:

Installed latest STEP, and am running the xLODGen.  Tried a few times, and nearly every time it fails with a message "Failure to add alpha layer on .." and the texture varies here on each run.

Also, I notice that the "bake normal-maps" checkmark setting on LOD32 makes all the other LODs also be checked (the guide says that it shouldn't be checked for LOD4, 8, 16).  If you disable it on LOD4, it disables for all other LODs too.

 

bugreport.txt 85.73 kB · 0 downloads LODGen_log.txt 316.88 kB · 0 downloads SSELODGen_log.txt 2.77 MB · 0 downloads

bake normal maps is a general setting that applies to all levels. That screen is only different because this setting was ticked for some reason when capturing it. Maybe the other three were updated and this one wasn't, IDK. I'll fix this eventually.

Moved to the xLODGen topic, since this is not an issue with the Step guide.

[sheson]

10 hours ago, kleshas said:

Installed latest STEP, and am running the xLODGen.  Tried a few times, and nearly every time it fails with a message "Failure to add alpha layer on .." and the texture varies here on each run.

Also, I notice that the "bake normal-maps" checkmark setting on LOD32 makes all the other LODs also be checked (the guide says that it shouldn't be checked for LOD4, 8, 16).  If you disable it on LOD4, it disables for all other LODs too.

 

bugreport.txt 85.73 kB · 0 downloads LODGen_log.txt 316.88 kB · 0 downloads SSELODGen_log.txt 2.77 MB · 0 downloads

From the log:
Error: Could not execute "Z:\mnt\nvme0n1p3\skyrimmodlists\STEP\Tools\xLODGen\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -sepalpha -aw 256 -srgb -f R8G8B8A8_UNORM -w 8 -h 8 -o "C:\users\steamuser\Temp\SSEEdit" "C:\users\steamuser\Temp\SSEEdit\39F9011240394BBAA77C9EFA8D9F385F.dds">
<Error creating textures for cell [-14,32] Could not create alpha layer with LDirtPath01 [LTEX:000B424C] (Textures\Landscape\DirtPath01.dds, Textures\Landscape\DirtPath01_N.dds) for [LAND:00004DAA]: A call to an OS function failed>.
Error converting textures: A call to an OS function failed

Search the forum for the error message finds this relevant thread:
https://stepmodifications.org/forum/topic/19354-linuxproton-a-call-to-an-os-function-failed/

Check that thread.

The hover hints for Bake normal-maps explains:
Bake blended normal-maps of landscape textures onto terrain model-space normals. Automatically applied to all LOD levels.

[Pr0bability]

Hello, as discussed briefly on Discord, I would like to present a few improvements for xLODGen, for FNV in particular.

For starters, thanks to https://www.nexusmods.com/newvegas/mods/84171, FNV's (and in extension TTW's) LOD capabilties are much higher than they were in vanilla. Many of the things that the game can actually support now are not supported by xLODGen. Me and several other authors have come up with a list of things that we feel like would be a huge improvement for FNV/TTW if implemented in xLODGen.

High priority object LOD improvements. Older Bethesda games do not have support for multiple levels of object LOD. FNV introduced the concept of high priority LOD, which while not used much in vanilla (only for i.e. Lucky 38 and other landmarks), can be used to great effect by modders. The new mod https://www.nexusmods.com/newvegas/mods/88898 aims to generalize this concept and broaden its use, to enable much more optimal LOD memory usage without sacrificing the overall quality. There are two very important improvements I perceive:

1. Use base form High Priority LOD flag. When xLODGen is generating high priority object LOD blocks, it checks the refs in the cells of the block for the High priority LOD flag. This works fine, but, as is the case with the above linked mod, means that if one wanted to use high priority LOD as a second LOD level (higher distances, less objects), they must go through every reference in every worldspace and properly assign these flags.
   This could be massively helped by also using the base form High Priority LOD flag (which is supported by xEdit). I can imagine it working like this - while generating high priority block, go through the refs and use those that are flagged Visible when Distant and either have, or their base form has, the High Priority LOD flag.
   This would massively help with any compatibility issues with using high priority LOD as a second LOD level, and thus make it more approachable for everyone.
2. High priority specific LOD meshes. To really enable high priority LOD to work as a second LOD level, we would also need to use a different set of meshes for it (that would be of less quality, but also much less taxing). As far as I can tell, when generating object LOD, xLODGen takes the Model FileName of a given ref's base form, and looks for <filename without extension>_lod.nif. Using a different suffix for high priority meshes (such as _high_lod.nif) should be easy to support. This combined with good LOD distance settings would mean that far away geometry could be simplified by a lot, saving on resources such as memory.
   I can imagine that extending this could look like:
   1. Generating high priority object LOD block
   2. Ref -> base form -> Model FileName -> object.nif
   3. Look for object_high_lod.nif
      1. Found - use it
      2. Not found - continue
   4. Look for object_lod.nif (fallback required, we can assume most forms would not have high priority mesh, definitely not for some time)
      1. Found - use it
      2. Not found - complain that LOD mesh is missing

These two improvements together would bring a true second level of LOD to FNV/TTW, and it would certainly be a complete game changer.

Split meshes / mesh shader properties / animations. The LOD Fixes and Improvements mod linked at the beginning changed the way work with generated LOD blocks - the limits on geometry and textures are removed, and the block meshes can be treated as any other nif - including various shader properties, multiple geometries, or animations.

Unfortunately, due to the way xLODGen works currently for FNV, all the LOD meshes are combined into a single geometry, "culled" by the terrain LOD, and saved. Therefore all of the original properties of the nifs are destroyed in the process. What would be great if we had the option to generate blocks with the original meshes not being combined and retaining their original properties. There are many many use cases for this, several I can think of:

• Emissives - lights in LOD
• Env mapping - reflections
• Animations - currently being used by mods like https://www.nexusmods.com/newvegas/mods/84173 which either means the user replaces theirs block with an edited one, or patch the LODGen output block mesh with the animated blocks themselves

A possible question is whether such a thing would make sense for all the refs in a block, or just those that have a certain property. I can imagine splitting everything could introduce a lot of unnecessary draw calls.

Edited August 28, 2024 by Pr0bability

[sheson]

8 hours ago, Pr0bability said:

Hello, as discussed briefly on Discord, I would like to present a few improvements for xLODGen, for FNV in particular.

For starters, thanks to https://www.nexusmods.com/newvegas/mods/84171, FNV's (and in extension TTW's) LOD capabilties are much higher than they were in vanilla. Many of the things that the game can actually support now are not supported by xLODGen. Me and several other authors have come up with a list of things that we feel like would be a huge improvement for FNV/TTW if implemented in xLODGen.

High priority object LOD improvements. Older Bethesda games do not have support for multiple levels of object LOD. FNV introduced the concept of high priority LOD, which while not used much in vanilla (only for i.e. Lucky 38 and other landmarks), can be used to great effect by modders. The new mod https://www.nexusmods.com/newvegas/mods/88898 aims to generalize this concept and broaden its use, to enable much more optimal LOD memory usage without sacrificing the overall quality. There are two very important improvements I perceive:

1. Use base form High Priority LOD flag. When xLODGen is generating high priority object LOD blocks, it checks the refs in the cells of the block for the High priority LOD flag. This works fine, but, as is the case with the above linked mod, means that if one wanted to use high priority LOD as a second LOD level (higher distances, less objects), they must go through every reference in every worldspace and properly assign these flags.
   This could be massively helped by also using the base form High Priority LOD flag (which is supported by xEdit). I can imagine it working like this - while generating high priority block, go through the refs and use those that are flagged Visible when Distant and either have, or their base form has, the High Priority LOD flag.
   This would massively help with any compatibility issues with using high priority LOD as a second LOD level, and thus make it more approachable for everyone.
2. High priority specific LOD meshes. To really enable high priority LOD to work as a second LOD level, we would also need to use a different set of meshes for it (that would be of less quality, but also much less taxing). As far as I can tell, when generating object LOD, xLODGen takes the Model FileName of a given ref's base form, and looks for <filename without extension>_lod.nif. Using a different suffix for high priority meshes (such as _high_lod.nif) should be easy to support. This combined with good LOD distance settings would mean that far away geometry could be simplified by a lot, saving on resources such as memory.
   I can imagine that extending this could look like:
   1. Generating high priority object LOD block
   2. Ref -> base form -> Model FileName -> object.nif
   3. Look for object_high_lod.nif
      1. Found - use it
      2. Not found - continue
   4. Look for object_lod.nif (fallback required, we can assume most forms would not have high priority mesh, definitely not for some time)
      1. Found - use it
      2. Not found - complain that LOD mesh is missing

These two improvements together would bring a true second level of LOD to FNV/TTW, and it would certainly be a complete game changer.

Split meshes / mesh shader properties / animations. The LOD Fixes and Improvements mod linked at the beginning changed the way work with generated LOD blocks - the limits on geometry and textures are removed, and the block meshes can be treated as any other nif - including various shader properties, multiple geometries, or animations.

Unfortunately, due to the way xLODGen works currently for FNV, all the LOD meshes are combined into a single geometry, "culled" by the terrain LOD, and saved. Therefore all of the original properties of the nifs are destroyed in the process. What would be great if we had the option to generate blocks with the original meshes not being combined and retaining their original properties. There are many many use cases for this, several I can think of:

• Emissives - lights in LOD
• Env mapping - reflections
• Animations - currently being used by mods like https://www.nexusmods.com/newvegas/mods/84173 which either means the user replaces theirs block with an edited one, or patch the LODGen output block mesh with the animated blocks themselves

A possible question is whether such a thing would make sense for all the refs in a block, or just those that have a certain property. I can imagine splitting everything could introduce a lot of unnecessary draw calls.

There is really no need for all these elaborate explanations. Just state the request.

Something like 1. and 2. has already been requested and will be included in the next beta version.

Combining shapes into several supershapes based on certain shader settings and passthrus like the later games also has already been requested and will be added to LODGen at some point. It is on the to do list. It just takes more consideration and time.

Combining meshes to reduce draw calls is the main reason for having LOD in the first place.

[theblackpixel]

It looks like a worldspace's terrain LOD stops being generated after a certain point for the worldspaces I am experimenting with. At first I thought the limit might be at 256 cells in either direction with the occlusion data limit being what it is but even when making a world smaller than that terrain generation just seems to stop at  a seemingly random point. The cut-off always seems to occur vertically, never horizontally. When I go near to the cells they load just fine but the LOD seemingly just was not generated. 

I know for a fact worlds of this scale can be made as worldspaces like Hoddminir have full LOD, however they did use Oscape.

BugReport.txt: https://paste.ee/p/ltHKS

Logs: https://rentry.co/r2seot8m

Is there any workaround for this/am I doing something wrong here?

[sheson]

7 hours ago, theblackpixel said:

It looks like a worldspace's terrain LOD stops being generated after a certain point for the worldspaces I am experimenting with. At first I thought the limit might be at 256 cells in either direction with the occlusion data limit being what it is but even when making a world smaller than that terrain generation just seems to stop at  a seemingly random point. The cut-off always seems to occur vertically, never horizontally. When I go near to the cells they load just fine but the LOD seemingly just was not generated. 

I know for a fact worlds of this scale can be made as worldspaces like Hoddminir have full LOD, however they did use Oscape

BugReport.txt: https://paste.ee/p/ltHKS

Logs: https://rentry.co/r2seot8m

Is there any workaround for this/am I doing something wrong here?

Upload the SSELODGen_log.txt instead of the LODGen.txt that shows successful object LOD generation.

Download the latest xLODGen terrain LOD beta from the first post. Unpack it into a new and empty folder. Then generate terrain LOD for the workspace and upload the new SSELODGen_log.txt and bugreport.txt if it exists.

[theblackpixel]

14 hours ago, sheson said:

Upload the SSELODGen_log.txt instead of the LODGen.txt that shows successful object LOD generation.

Download the latest xLODGen terrain LOD beta from the first post. Unpack it into a new and empty folder. Then generate terrain LOD for the workspace and upload the new SSELODGen_log.txt and bugreport.txt if it exists.

Hello, 

I have followed the instructions as provided, unfortunately I still have the same issue. See the SSELODGen_Logs.txt attached below as requested:

https://ufile.io/rfcypdtq

[sheson]

11 hours ago, theblackpixel said:

Hello, 

I have followed the instructions as provided, unfortunately I still have the same issue. See the SSELODGen_Logs.txt attached below as requested:

https://ufile.io/rfcypdtq

You might need to create a lodsettings file with a stride of 512. It looks like you just copied an existing file instead of creating one. However a stride over 256 is untested with xLODGen generation. It looks though like terrain LOD meshes have been generated for the found area. I have no idea if CK or the game support loading LOD beyond the origin + stride or support a stride > 256.

The reason is, that the working playable area in the game is from -64 to +64 (it is possible one direction has -128 to +128) Beyond that activators and other stuff stops working properly. So, there is not much use of a worldspace being larger than +- 192  or maybe +-256 until somebody fixes that in the engine. Hence for now supporting a stride over 256 does not seem to be needed.

Injecting the cells might cause problems, too. Best would be an esm adding the cells normally.

I would test if a worldspace with -256 to 256 with a LODsettings file with the correct -256, -256 SW origin and a stride of 256 works. See LODSettings-File-Readme.txt

If you can not get it to work, upload the plugins(s).

[Kattmandu]

SSELODGen 4.1.4b keeps aborting.

...
...
[03:58] f:\tools\xlodgen\xlodgen_output\textures\terrain\tamriel\tamriel.4.60.4.dds
Operation aborted

bugreport.txt

 

 

Edited September 26, 2024 by Kattmandu

[sheson]

1 hour ago, Kattmandu said:

SSELODGen 4.1.4b keeps aborting.

...
...
[03:58] f:\tools\xlodgen\xlodgen_output\textures\terrain\tamriel\tamriel.4.60.4.dds
Operation aborted

bugreport.txt 771.48 kB · 1 download

Use the latest version from first post instead of a 2 year old version.

Check the load order for errors with xEdit and fix errors before generating LOD.
If problem persists, post the entire SSELODGen_log.txt, new bugreport.txt.

[Kattmandu]

21 minutes ago, sheson said:

Use the latest version from first post instead of a 2 year old version.

Check the load order for errors with xEdit and fix errors before generating LOD.
If problem persists, post the entire SSELODGen_log.txt, new bugreport.txt.

LOL, didn't realize there was an update.  Is there a way to subscribe to update notifications?

 

EDIT:  Just added the xLODGen channel to my Discord.  Will check there periodically for build updates.

Edited September 26, 2024 by Kattmandu

[sheson]

16 minutes ago, Kattmandu said:

LOL, didn't realize there was an update.  Is there a way to subscribe to update notifications?

You could follow this topic (though I do not know if title changes whenever the version changes are included) or follow the discord channel linked in the first post for the changelog.

[nalathequeen2186]

Hello, I'm having a problem with xLODGen and my in-game map. My map in-game is extremely low quality and has jagged water instead of smooth shorelines. The first time this happened, I assumed it was some kind of issue with my map mod (A Quality World Map), so I swapped it out for a more up-to-date one (A Clear Map of Skyrim and Other Worlds). For a little while it worked fine, then the problem inexplicably appeared again after playing for a few more hours, and nothing I've done has been able to fix it.

I looked up help online, and every source I found of people having this same problem (x, x, x, x) traced it back to an issue with the xLODGen output. Every source said their issue was fixed either by regenerating the terrain LOD while following these instructions exactly (which I have done, but the problem still persists), or deleting all the meshes and textures for LOD level 32 in the xLODGen output folder (which just resulted in my entire map having no meshes or textures at all). I'm at a loss as to how to continue to try to troubleshoot this problem.

[sheson]

48 minutes ago, nalathequeen2186 said:

Hello, I'm having a problem with xLODGen and my in-game map. My map in-game is extremely low quality and has jagged water instead of smooth shorelines. The first time this happened, I assumed it was some kind of issue with my map mod (A Quality World Map), so I swapped it out for a more up-to-date one (A Clear Map of Skyrim and Other Worlds). For a little while it worked fine, then the problem inexplicably appeared again after playing for a few more hours, and nothing I've done has been able to fix it.

I looked up help online, and every source I found of people having this same problem (x, x, x, x) traced it back to an issue with the xLODGen output. Every source said their issue was fixed either by regenerating the terrain LOD while following these instructions exactly (which I have done, but the problem still persists), or deleting all the meshes and textures for LOD level 32 in the xLODGen output folder (which just resulted in my entire map having no meshes or textures at all). I'm at a loss as to how to continue to try to troubleshoot this problem.

Moved to the xLODGen thread. Upload the SSELODGen_log.txt when making posts.
If you follow third party instructions, you need to ask their author/their forum for help. It is rather pointless linking to third party forums and discussion.

See the first post:
Set Optimize Unseen to off for LOD4 for first generation. Start experimenting with a value of 550 with a quality setting of 10 or lower for LOD32 (used for map) and compare coastlines and file size to other settings.

https://dyndolod.info/Help/xLODGen#Generating-Terrain-LOD-Meshes
Typically use a Quality of 0 to 10 for LOD32 and set Optimize Unseen to 550 to improve coastlines on the map.

These settings will generate terrain LOD meshes for LOD level 32 that will have greatly detailed coastlines.

See https://dyndolod.info/Mods/Maps-And-Map-Mods

Also pay attention to this in the first post:
Use -o:"c:\OutputPath\" command line parameter to change where files are generated to, default is the game folder. Then install output as a mod.
Do not generate into any game, any mod manager folders or special Windows folder like Program Files x86, Users, Desktop, Documents, Downloads etc.

Or in the Readme.txt
Always set -o:"c:\OutputPath\" command line argument to change where files are generated to. The default is the game folder which risks replacing existing files and is problematic with mod managers, especially if they use some kind of virtualization. Do not generate into any game or any mod manager folders that are part (direct or indirect) of the virtual file system. Do not generate into the Overwrite folder of MO2.

Or here: https://dyndolod.info/Help/xLODGen#Installation
To start xLODGen in the desired game mode, it should be set as a command line argument in addition to setting a dedicated output folder with -o:"c:\OutputPath\" as explained in the Readme.txt included in the xLODGen download archive. For example: "C:\Modding\xLODGenx64.exe" -sse -o:"c:\Output\"
Do not generate into game or mod manager folders. Just as with TexGen or DynDOLOD, always set and generate into a dedicated output folder and once generation is dome, install the output as a mod.

Make sure you understand how the mod manager you are using works.
Make sure you know how to set the overwrite order of mods (their of assets) correctly so that the desired terrain LOD meshes for LOD level 32 win (are loaded last).

xLODGen is a tool to generate LOD meshes and textures which should be generated into a dedicated output folder and then installed as  a mod as explained.
Removing the mod with the meshes / textures means the game will load the vanilla terrain LOD meshes / textures from the vanilla BSA again. If not, the INIs are not default or a 3rd party mod might be changing things.