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

[sheson]

  On 8/26/2019 at 5:17 PM, finedandy said:

Can you please upload a mirror for your download? The Mega link shows me a "Temporary error, retrying." and I already tried everything possible.

I re-uploaded it so it gets a new URL. It works for me now.

[finedandy]

  On 8/26/2019 at 6:15 PM, sheson said:

I re-uploaded it so it gets a new URL. It works for me now.

Thank you it works now!

[sheson]

xLODGen beta 47
fixes an issue with FO4 vertex alpha
added TVDT Occlusion data generation for Skryim/Enderal/Skyrim VR/Skyrim Special Edition
 
xLODGen beta 48
fixes looking for some wrong object LOD texture filenames in FO4

 

xLODGen beta 49

ignore wild edit cells that are out of range for occlusion

 

xLODGen beta 50

fix an error reading object LOD meshes for occlusion
 
 
See the included Skyrim-Occlusion-Readme.txt for a brief explanation of the Skyrim TVDT Occlusion data generation. Read the hints that are shown when the mouse pointer rests on a setting. Ask specific questions or give feedback in the dedicated Skyrim TVDT - Occlusion Data thread.

Edited September 7, 2019 by sheson

[Martimius]

Is it safe to compress the generated meshes and textures after the tool is run into a bsa to improve game loading times?

[Tacocat]

  On 9/7/2019 at 10:06 AM, Martimius said:

Is it safe to compress the generated meshes and textures after the tool is run into a bsa to improve game loading times?

I am doing that for some time now and noticed less stutter. Depending on your settings, you can get multiple bsa archives. I got 9 archives, which means 9 plugins to load them. But they can easily be marked .esl. Works fine for me so far. Might aswell add those to the skyrim.ini archive list, but i dont know if there is a maximum number of archives that can be added/loaded.

[sheson]

  On 9/7/2019 at 10:06 AM, Martimius said:

Is it safe to compress the generated meshes and textures after the tool is run into a bsa to improve game loading times?

Always the same answer: Only do this if really know what you are doing. Asking the question is kind of a hint :)

Nothing else should overwrite any of the files. If there are data files for the SKSE plugins, they need to be loose. I do not support it. 

 

If you are using Skryim Special Edition Consider using/testing https://github.com/Ryan-rsm-McKenzie/FileCacheSSE/releases

Edited September 7, 2019 by sheson

[Martimius]

  On 9/7/2019 at 11:53 AM, sheson said:

Always the same answer: Only do this if really know what you are doing. Asking the question is kind of a hint :)

Nothing else should overwrite any of the files. If there are data files for the SKSE plugins, they need to be loose. I do not support it. 

 

If you are using Skryim Special Edition Consider using/testing https://github.com/Ryan-rsm-McKenzie/FileCacheSSE/releases

Thanks for the reply. I've managed to compress the BSA, but only the files that Mod Organizer said didn't conflict with anything. The rest stayed loose. Would you know what this File Cache SSE is exactly supposed to do? Nothing's really said on the GitHub.

Edited September 7, 2019 by Martimius

[sheson]

  On 9/7/2019 at 4:01 PM, Martimius said:

Thanks for the reply. I've managed to compress the BSA, but only the files that Mod Organizer said didn't conflict with anything. The rest stayed loose. Would you know what this File Cache SSE is exactly supposed to do? Nothing's really said on the GitHub.

It's function is in the name. It caches requests to files. That speeds up loading a bit.

[Martimius]

  On 9/7/2019 at 4:15 PM, sheson said:

It's function is in the name. It caches requests to files. That speeds up loading a bit.

Thanks for your speedy reply! Yeah, definitely sounds like a good addition to everyone's installs.

 

My xLODGen run seemed to go smoothly with no errors in the program or noticeable graphical artifacts in-game. I did notice the Solstheim texture file was astronomically large though, compared to Tamriel. Tamriel's was only 835mb, while Solstheim's was at a whopping 2.01 GB. I also noticed there were much more generated files (Tamriel ~2000, Solstheim ~6000). Why is this? Isn't it a much smaller worldspace?

[sheson]

  On 9/7/2019 at 4:40 PM, Martimius said:

Thanks for your speedy reply! Yeah, definitely sounds like a good addition to everyone's installs.

 

My xLODGen run seemed to go smoothly with no errors in the program or noticeable graphical artifacts in-game. I did notice the Solstheim texture file was astronomically large though, compared to Tamriel. Tamriel's was only 835mb, while Solstheim's was at a whopping 2.01 GB. I also noticed there were much more generated files (Tamriel ~2000, Solstheim ~6000). Why is this? Isn't it a much smaller worldspace?

The messages in the log have the answer:

 

[Tamriel] Land height: -27000, Water height: -14000, Scanned: 11186 CELL records, Found: 11186 LAND records for area [-57,-43] to [61,50]

 

[DLC2SolstheimWorld] Land height: -4590, Water height: 256, Scanned: 34557 CELL records, Found: 34383 LAND records for area [-64,-64] to [127,127]

Edited September 7, 2019 by sheson

[Martimius]

Alright, is there any way to mitigate this though, like reduce the amount of records needed by xLODGen to effectively generate Terrain LOD for the Solstheim worldspace? I'm looking to save whatever space I can since my SSD is already starting to get full. 

 

 

On another note though, is it really needed to generate Terrain LOD for worldspaces like Tamriel, even though it could be included in a mod already?

 

 

 

EDIT: It seems the Readme has answered this, "If terrain LOD textures already exist in the output folder, their generation will be skipped. This can be used to continue generating terrain LOD textures for large worldspaces in case there was a problem like not enough space left on a drive. Simply restart with the same options. Otherwise move or selectively delete old terrain LOD textures before generating new ones."

 

So in my understanding if Terrain LOD already exists we don't have to use xLODGen if we just put the Terrain LOD files in the designated output folder (-o startup parameter), and I can just move onto generating object and Tree LOD in DynDOLOD right away?

Edited September 8, 2019 by Martimius

[sheson]

  On 9/8/2019 at 5:53 AM, Martimius said:

Alright, is there any way to mitigate this though, like reduce the amount of records needed by xLODGen to effectively generate Terrain LOD for the Solstheim worldspace? I'm looking to save whatever space I can since my SSD is already starting to get full. 

 

 

On another note though, is it really needed to generate Terrain LOD for worldspaces like Tamriel, even though it could be included in a mod already? An example would be Landscapes- Cathedral Concept: https://www.nexusmods.com/skyrimspecialedition/mods/21954?tab=files

 

 

 

EDIT: It seems the Readme has answered this, "If terrain LOD textures already exist in the output folder, their generation will be skipped. This can be used to continue generating terrain LOD textures for large worldspaces in case there was a problem like not enough space left on a drive. Simply restart with the same options. Otherwise move or selectively delete old terrain LOD textures before generating new ones."

 

So in my understanding if Terrain LOD already exists we don't have to use xLODGen if we just put the Terrain LOD files in the designated output folder (-o startup parameter), and I can just move onto generating object and Tree LOD in DynDOLOD right away?

Use the Specific Chunk option to limit generation to specific areas / LOD levels.

 

I suggest to always generate terrain LOD meshes (wuth protect cell borderoption) for the current load order, since its quick and will make sure the changes of all mods are considered.

If existing terrain LOD textures already match the load order well then there is no need to generate them. Simply uncheck their generation.

Edited September 8, 2019 by sheson

[Martimius]

  On 9/8/2019 at 6:03 AM, sheson said:

Use the Specific Chunk option to limit generation to specific areas / LOD levels.

 

I suggest to always generate terrain LOD meshes (wuth protect cell borderoption) for the current load order, since its quick and will make sure the changes of all mods are considered.

If existing terrain LOD textures already match the load order well then there is no need to generate them. Simply uncheck their generation.

Oh, ok then. I guess in my case I would need to generate Terrain LOD, seeing as the existing one from Cathedral Landscapes comes bundled with it and is independent from my load order. 

[Martimius]

Hey sheson, I know you've suggested for us to use the 512 texture size for LOD generation, but if we really want to get more fps, would halving it down to 256 be a good idea?

[sheson]

  On 9/9/2019 at 12:58 PM, Martimius said:

Hey sheson, I know you've suggested for us to use the 512 texture size for LOD generation, but if we really want to get more fps, would halving it down to 256 be a good idea?

Nobody but you can answer that question for your setup, load order and hardware. The only way to know for sure is to test.

 

Reducing texture resolution with one of the available 3rdp party tools should be quicker than running xLODGen.