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

[sheson]

  On 4/15/2025 at 5:35 AM, miversen33 said:

So an interesting discovery. I happen to have a previously unused windows 10 machine with a GPU that is "capable" of running SSE VR. So I fired it up, wiped windows 10, installed SSE VR (and the bare minimum relevant tools), and xlodgen worked just fine. Here is the output
https://paste.ee/p/HiGAJs5c

Now, I am _not_ convinced it actually worked, as I see no mention of any of the `.dds` files it was complaining about before. But it certainly didn't fail and there are no black terrains in the distance now.

I have not yet tried this on my main machine, so that is my next step. If it works, then indicates there is something wrong with the mo2 instance that is provided by the FUS wabbajack. 

Not exactly sure just yet, but progress

Expand  

You reported the error also happens while running xLODGen outside of MO2, which I take means it was started while MO2 was not running. In that case it is typically more like an OS issue - and whatever tools tie into file access/reading.

Are there any other command lines being used other than -sse and -o? I assume -d -m and -p? Copy and paste them.

[KRZ]

Good day,
would it be within the realm of possibilites for xLODGen to apply some form of stochastic texturing during terrain lod generation to prevent obvious tiling or is that impossible due to how textures are being processed? 

Thank you very much for any explanation!

[z929669]

  On 4/15/2025 at 1:45 PM, KRZ said:

Good day,
would it be within the realm of possibilites for xLODGen to apply some form of stochastic texturing during terrain lod generation to prevent obvious tiling or is that impossible due to how textures are being processed? 

Thank you very much for any explanation!

Expand  

textures\terrain\noise.dds is used for exactly this purpose. Just search for "terrain noise" to experiment with different ones.

[sheson]

  On 4/15/2025 at 1:45 PM, KRZ said:

Good day,
would it be within the realm of possibilites for xLODGen to apply some form of stochastic texturing during terrain lod generation to prevent obvious tiling or is that impossible due to how textures are being processed? 

Thank you very much for any explanation!

Expand  

Terrain LOD is splatted from the full terrain textures and layer information so it matches. If someone were to make a mod/shader to change full terrain works in one of the supported games, we would try to accommodate that.

[KRZ]

  On 4/15/2025 at 2:24 PM, z929669 said:

textures\terrain\noise.dds is used for exactly this purpose. Just search for "terrain noise" to experiment with different ones.

Expand  

I do use those, but a dev on CS' discord is working on a shader and considered extending it to LOD, which brought up the question. Thank you though!
To sheson as well for the explanation and not entirely ruling out the possibility. 

Edited April 15 by KRZ

[miversen33]

> You reported the error also happens while running xLODGen outside of MO2, which I take means it was started while MO2 was not running. In that case it is typically more like an OS issue - and whatever tools tie into file access/reading.

 

This is correct. I am reasonably convinced the issue is os basd. Not 100% yet, still working through a few tests. I copied the flags I used and xLODGen settings I used over to the "new" pc so in theory everything should have been the same. The only difference is that I did use MO2 to run xlodgen on the new pc (though without the wabbajack).

My flags are simply `-tes5vr -o:"F:\LodGen\xLodGen" -t:"F:\tmp\xLODGen"`. Nothing crazy. I am currently installing MO2 and going to reinstall skyrim vr altogether. I want to see if just starting fresh without the wabbajack and portable (provided) mo2 instance will let this go through.

Maybe after I have figured that out we can work back up to figure out what is causing the error I am experiencing with my Load Order

[miversen33]

  On 4/15/2025 at 8:05 PM, miversen33 said:

> You reported the error also happens while running xLODGen outside of MO2, which I take means it was started while MO2 was not running. In that case it is typically more like an OS issue - and whatever tools tie into file access/reading.

 

This is correct. I am reasonably convinced the issue is os basd. Not 100% yet, still working through a few tests. I copied the flags I used and xLODGen settings I used over to the "new" pc so in theory everything should have been the same. The only difference is that I did use MO2 to run xlodgen on the new pc (though without the wabbajack).

My flags are simply `-tes5vr -o:"F:\LodGen\xLodGen" -t:"F:\tmp\xLODGen"`. Nothing crazy. I am currently installing MO2 and going to reinstall skyrim vr altogether. I want to see if just starting fresh without the wabbajack and portable (provided) mo2 instance will let this go through.

Maybe after I have figured that out we can work back up to figure out what is causing the error I am experiencing with my Load Order

Expand  

Well, I completely removed any trace of Skyrim VR from my machine (including all saves and temp data), reinstalled it fresh, and I am still seeing the errors I was seeing before after copying the functional settings from my other machine. At this point this has to be OS based. I don't know what or why, but nothing else makes any sense. I have already disabled the only AV I have (windows defender). Before I do something drastic like completely blowing away windows and starting fresh, is there anything else you recommend I look at?

Most recent "failed" lodgen logs
https://paste.ee/p/CHxwclOH

[miversen33]

  On 4/15/2025 at 8:33 PM, miversen33 said:

Well, I completely removed any trace of Skyrim VR from my machine (including all saves and temp data), reinstalled it fresh, and I am still seeing the errors I was seeing before after copying the functional settings from my other machine. At this point this has to be OS based. I don't know what or why, but nothing else makes any sense. I have already disabled the only AV I have (windows defender). Before I do something drastic like completely blowing away windows and starting fresh, is there anything else you recommend I look at?

Most recent "failed" lodgen logs
https://paste.ee/p/CHxwclOH

Expand  

So this is crazy. I completely wiped my pc. Like, deleted everything on the c drive, reinstalled windows 10, and literally started over from scratch. Below is my load order
Paste.ee - Load Order

Regenerated xlodgen (log: Paste.ee - Lodgen logs)
xlodgen flags: `-tes5vr -o:"F:\LodGen\xLodGen" -t:"F:\tmp\xLODGen"`

With all of this shenaniganery, I _still_ have that black lod in the distance. No errors reported in the xlodgen but still no dice. What on earth am I missing? It worked on a completely different machine but for some reason I can't get it working on the actual gaming PC I am using. I am so very confused

[sheson]

  On 4/16/2025 at 3:28 AM, miversen33 said:

So this is crazy. I completely wiped my pc. Like, deleted everything on the c drive, reinstalled windows 10, and literally started over from scratch. Below is my load order
Paste.ee - Load Order

Regenerated xlodgen (log: Paste.ee - Lodgen logs)
xlodgen flags: `-tes5vr -o:"F:\LodGen\xLodGen" -t:"F:\tmp\xLODGen"`

With all of this shenaniganery, I _still_ have that black lod in the distance. No errors reported in the xlodgen but still no dice. What on earth am I missing? It worked on a completely different machine but for some reason I can't get it working on the actual gaming PC I am using. I am so very confused

Expand  

The log shows this once:
<Warning: Unknown texture format textures\landscape\dirt02.dds>
<Warning: Error loading texture textures\landscape\dirt02.dds>

Also not all LOD textures are actually generated:
<Notice: Skipping chunk 32 [-64,-64] because file already exists: f:\lodgen\xlodgen\textures\terrain\tamriel\tamriel.32.-64.-64.dds>

Terrain-LOD-Readme.txt
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.

Make sure the output folder is empty. Then generate again. Report if there are still warnings about unknown texture format and/or error loading texture.

[miversen33]

  On 4/16/2025 at 6:00 AM, sheson said:

The log shows this once:
<Warning: Unknown texture format textures\landscape\dirt02.dds>
<Warning: Error loading texture textures\landscape\dirt02.dds>

Also not all LOD textures are actually generated:
<Notice: Skipping chunk 32 [-64,-64] because file already exists: f:\lodgen\xlodgen\textures\terrain\tamriel\tamriel.32.-64.-64.dds>

Terrain-LOD-Readme.txt
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.

Make sure the output folder is empty. Then generate again. Report if there are still warnings about unknown texture format and/or error loading texture.

Expand  

I've finally figured it out! The `-t` flag is what is breaking things.

 

If I remove the `-t` flag, it works just fine. I didn't add the `t` flag in my test on my other machine because I only had one drive in there, so it didn't even occur to me that that might be what is going on.

lots of logs
TES5VRLODGen_log (no flags).txt

TES5VRLODGen_log (using t and o flag).txt

TES5VRLODGen_log (using t flag on same drive).txt

TES5VRLODGen_log (using t flag).txt

TES5VRLODGen_log(using o flag).txt

 

I don't know _why_ the `t` flag is breaking stuff, and I do need it if I am going to generate lods for my load order as my `C:` drive is much too small (it's a 128Gb ssd).

Some notes about the setup here.

`C:` is a 128Gb ssd connected over SATA

`D:` is a 2Tb nvme

`E:` is a 500Gb ssd connected over SATA

`F:` is a 4Tb ssd connected over SATA

Its a hodgepodge of drives lol. But they are _all_ SSDs so this isn't some weird shenaniganry with spinning disks. And I even tried using the same drive that xlodgen is on as temp. It failed in all cases.

 

 

Edited April 16 by miversen33
Added more logs

[sheson]

  On 4/16/2025 at 2:37 PM, miversen33 said:

I've finally figured it out! The `-t` flag is what is breaking things.

 

If I remove the `-t` flag, it works just fine. I didn't add the `t` flag in my test on my other machine because I only had one drive in there, so it didn't even occur to me that that might be what is going on.

lots of logs
TES5VRLODGen_log (no flags).txt

TES5VRLODGen_log (using t and o flag).txt

TES5VRLODGen_log (using t flag on same drive).txt

TES5VRLODGen_log (using t flag).txt

TES5VRLODGen_log(using o flag).txt

 

I don't know _why_ the `t` flag is breaking stuff, and I do need it if I am going to generate lods for my load order as my `C:` drive is much too small (it's a 128Gb ssd).

Some notes about the setup here.

`C:` is a 128Gb ssd connected over SATA

`D:` is a 2Tb nvme

`E:` is a 500Gb ssd connected over SATA

`F:` is a 4Tb ssd connected over SATA

Its a hodgepodge of drives lol. But they are _all_ SSDs so this isn't some weird shenaniganry with spinning disks. And I even tried using the same drive that xlodgen is on as temp. It failed in all cases.

Expand  

The error happens after trying to load the texture file from the data folder or BSA though.

Maybe set the tmp and temp path to a stable drive/folder. https://knowledge.civilgeo.com/changing-the-windows-temp-and-tmp-directory/

https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.6/xEdit/xeInit.pas#L357

[miversen33]

  On 4/16/2025 at 4:12 PM, sheson said:

The error happens after trying to load the texture file from the data folder or BSA though.

Maybe set the tmp and temp path to a stable drive/folder. https://knowledge.civilgeo.com/changing-the-windows-temp-and-tmp-directory/

https://github.com/TES5Edit/TES5Edit/blob/dev-4.1.6/xEdit/xeInit.pas#L357

Expand  

I did test that after I uploaded my previous comment. 

My original load order would usually generate a lod that was around 20Gb. I haven't tested that build on this yet since that takes a while, but I have noticed that removing the `-t` flag and setting the temp/tmp environment variables instead did seem to "work". Though I am not completely sure if it properly utilized the "new" temporary location yet, I suppose I will find that out when I try my full load order this afternoon.

In any case, it seems that I have a workaround which is great. Any idea what would cause that flag to throw this error? I don't mind (in my case) shifting my entire OS temp directory to another location but that seems like a rather large ask for most users, especially when xlodgen has the ability to utilize a temporary directory via command line flags.

I am more than willing to use my machine as a test bed for figuring that out if you would like or if you cannot recreate the issue on your side.

[sheson]

  On 4/16/2025 at 5:21 PM, miversen33 said:

I did test that after I uploaded my previous comment. 

My original load order would usually generate a lod that was around 20Gb. I haven't tested that build on this yet since that takes a while, but I have noticed that removing the `-t` flag and setting the temp/tmp environment variables instead did seem to "work". Though I am not completely sure if it properly utilized the "new" temporary location yet, I suppose I will find that out when I try my full load order this afternoon.

In any case, it seems that I have a workaround which is great. Any idea what would cause that flag to throw this error? I don't mind (in my case) shifting my entire OS temp directory to another location but that seems like a rather large ask for most users, especially when xlodgen has the ability to utilize a temporary directory via command line flags.

I am more than willing to use my machine as a test bed for figuring that out if you would like or if you cannot recreate the issue on your side.

Expand  

Try adding a trailing \ to the path. -t:"F:\tmp\xLODGen\"

[miversen33]

  On 4/17/2025 at 3:01 AM, sheson said:

Try adding a trailing \ to the path. -t:"F:\tmp\xLODGen\"

Expand  

It worked, though I am unsure if that is due to adding the `\` at the end or having moved my entire temporary space with environment variables. In either case though, no errors/warnings

https://paste.ee/p/veigXM2U

[amgtkt]

xlodgen has never worked for me, i keep generating over and over but there isnt a single difference between my vanilla lods and the generated one

landscape and grass mods disabled, xlodgen off : https://pasteboard.co/mF10INYPxZyG.jpg

folkvangr (which has a tundra texture) on and xlodgen generated : https://pasteboard.co/pDJzRth5Ib1e.jpg

my xlodgen takes ~5 minutes for around 600mb filzesize, what's happening? I launch it and tick the Terrain lod option and all worlds too ; https://pasteboard.co/X344lvSlvpG0.png , I have played with the quality settings but nothing works

nevermind I somehow managed to make it work by crashing my entire pc when generating the lods (set everything to the highest) and now it works...

Just need to teak the brighness and contrast a bit for Folkvangr but it's all good now...