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

[MITSUYOMI]

Hello, Im trying to add lods for certain objects but upon running lodgen this comes up. I did it by copying the statics' mesh file path to the lod file path in xedit, since assigning Full LOD to the references in the record header wont work.

 

Error accessing parsing line An item with the same key has already been added. What does this mean?

[sheson]

47 minutes ago, MITSUYOMI said:

Hello, Im trying to add lods for certain objects but upon running lodgen this comes up. I did it by copying the statics' mesh file path to the lod file path in xedit, since assigning Full LOD to the references in the record header wont work.

Error accessing parsing line An item with the same key has already been added. What does this mean?

It means there is a line with the same key. Keys for things need to be unique.

If help is required, properly report the problem by providing common sense information, like logs, screenshots, load order etc.

[Kattmandu]

Ran SSELODGen today after updating DynDOLOD Resources SE 3 to Alpha-52 and DynDOLOD 3.00 to Alpha-179 and it aborted, didn't crash or close, just stopped generating.  Haven't had this happen before.  Bug report below.

 bugreport.txt

 

EDIT:  Interesting, ran it again and it completed.

Edited August 25 by Kattmandu

[sheson]

30 minutes ago, Kattmandu said:

Ran SSELODGen today after updating DynDOLOD Resources SE 3 to Alpha-52 and DynDOLOD 3.00 to Alpha-179 and it aborted, didn't crash or close, just stopped generating.  Haven't had this happen before.  Bug report below.

  bugreport.txt 131.27 kB · 0 downloads

Upload the SSELODGen_log.txt

What do you believe updating DynDOLOD or DynDOLOD Resources have to with xLODGen and terrain LOD generation in particular?
Generate terrain LOD before running TexGen and DynDOLOD.

Make sure to use the latest xLODGen terrain LOD beta version linked from first post.

Error check the load order with xEdit.

[Kattmandu]

2 minutes ago, sheson said:

What do you believe updating DynDOLOD or DynDOLOD Resources have to with xLODGen and terrain LOD generation in particular?

LOL, I suppose nothing.  Not sure why I even bothered regenerating XLODGen output after updating DynDOLOD and DynDOLOD Resources.  I suppose I was unsure if DynDOLOD modified landscape textures but after checking the files structure in Resources, it appears there isn't a landscape subfolder in the textures folder.

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