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

[combatfun]

  On 4/22/2019 at 5:58 PM, darksynth0 said:

Awesome!

Got it fixed by dedicating xLODGEN ouput outside of MO (thanks for helping though).

Strange thing that it does work on my laptop and meshes and textures are getting into MO2's overwrite folder without any TexConv issues (no additional arguments).

But on my PC it only works with -o:"somedisc:\xLODGen\OUTPUT" argument.

Windows 10 version are identical, with all UAC/AV stuff configured, and all Admin and write privileges given.

 

Go figure I suppose.

 

 

Hello, i have the same issue as you. Can you please describe in more details, how you solved it?

Where to enter the argument and where can the generated data be found, if they won't go in the overwrite folder of mo2? Enter argument here in mo2?

 

I did not have this issue before, and i only added NSUTR+comp.Patches and updated to the new 2.2 MO2 version. I've already checked the newest DynDoLOD version and started from scratch.

Sadly the error message is still there. In fact, only LODs for/from Tamriel.esm can be generated... :/

Edited May 12, 2019 by combatfun

[sheson]

  On 5/12/2019 at 10:03 AM, combatfun said:

 

Hello, i have the same issue as you. Can you please describe in more details, how you solved it?

Where to enter the argument and where can the generated data be found, if they won't go in the overwrite folder of mo2? Enter argument here in mo2?

 

I did not have this issue before, and i only added NSUTR+comp.Patches and updated to the new 2.2 MO2 version. I've already checked the newest DynDoLOD version and started from scratch.

Sadly the error message is still there. In fact, only LODs for/from Tamriel.esm can be generated... :/

 

Generic questions how to use MO should be asked on a support forum etc. for MO. We provide xLODGen support here.

 

As the first post and the included readme explain, the command line parameter to set a dedicated output folder is something like -o:"c:\OutputPath\"

 

Just setting -o is not going to do anything.

[combatfun]

Ok understood, thanks. 

[vhbenin]

Hello, i modded skyrim a while back when terrain lod was at it`s early stages,  

 

i`m preteding to mod  the game from scratch again when step 3.0 SSE comes

 

i have a quick question: what`s the best configuration for the terrain lod by you guys testings? 

 

i have an 8700k and an 1080Ti

 

i used to run dyndolod with trees at full model lod 4, lod 4 at lod 8 and lod 8 at lod 16

 

what about terrain lod, what are the options for an ultra or beyond ultra configuration?

[Astakos]

Hi sheson,

 

Using MO 2.2.0 & xLODGen Beta 42. I have set it up in MO correctly (using xLODGen almost since its release, so the setup is not an issue), but I am facing a very weird behavior.

 

xLODGen stops at times its terrain generation with a "Invalid lod settings" pop-up window. I never had any invalid lod settings in all the mods I am using (most of my ***world.lod files are loose; I have extracted the BSAs) so I thought I should check these files to see if I can spot anything. After a lot of testing what I spotted was that xLODGen, during generation, arbitrarily replaces some of the original *world.lod files in MO with its own that seem to be quite corrupted.

Let me give you an example (results of my latest test last night):

 

This is a screenshot of my setup: https://www.dropbox.com/s/v253jktkkzstgi9/Screenshot%202019-05-13%2011.12.56.png?dl=0

 

xLODGen was doing its thing and then just after generating "mannyGFOworld" (from The Gray Cowl of Nocturnal mod) it stops and the "Invalid lod settings" window appears.

Then I opened the mannygfo.lod file and its contents are completely invalid...have a look pls:

 

 

  Reveal hidden contents

 

============================================================

Skyrim Object LOD Generator 2.5.6.0

Created by Ehamloptiran and Zilav

Updated by Sheson

 

Log started at 05:27:58

Game Mode: TERRAINSSE

Generating terrain LOD for worldspace mannyGFO

Reading E:\xLODGen Beta 42\Edit Scripts\LODGen_Terrain_mannyGFO.bin

Data from -64,-64 to 63,63

Protect Cell Border LOD 4: True

Specific level: No

Max Level: 32

Specific quad: No

Output: E:\xLODGen Beta 42\xLODGen Output\meshes\terrain\mannyGFO\

Quality LOD32: 13   Max Vertices: 30767   Optimize Unseen: 550

Quality LOD16: 10   Max Vertices: 30767   Optimize Unseen: 0

Quality LOD8: 10   Max Vertices: 30767   Optimize Unseen: 0

Quality LOD4: 5   Max Vertices: 30767   Optimize Unseen: -1

Finished LOD level mannyGFO.32.0.-32.btr [1083/2034]

Finished LOD level mannyGFO.32.32.-32.btr [640/2048]

Finished LOD level mannyGFO.32.-32.-64.btr [640/2048]

Finished LOD level mannyGFO.32.0.-64.btr [640/2048]

Finished LOD level mannyGFO.32.-64.-32.btr [640/2048]

Finished LOD level mannyGFO.32.-64.0.btr [640/2048]

Finished LOD level mannyGFO.32.-64.-64.btr [792/2046]

Finished LOD level mannyGFO.32.-32.-32.btr [1059/2042]

Finished LOD level mannyGFO.32.32.-64.btr [640/2048]

......and so on

Log ended at 05:28:12 (0:14)

 

 

 

Which simply means that xLODGen copied the contents of its log file for the given world into the actual mannygfo.lod file in the lodsettings folder in MO !!!!

 

I went through all the *.lod files in MO and found another one (arnimadagonrealm.lod from Beyond Reach mod) that xLODGen had replaced the contents with the log file of BSHeartland which in turn was a worldspace that I hadn't even selected !!!!

 

From what I have noticed through my various tests, which actual *world.lod it corrupts is completely arbitrary. I have the feeling that since xLODGen halts complaining about an invalid lod settings file; then there is strong possibility that one the files it corrupts should be for a worldspace not yet generated and when xLODGen comes to its generation it then sees the corrupted file and stops.

 

If I do 1 worldspace at a time then no corruption appears.

 

Any thoughts please?

[sheson]

  On 5/13/2019 at 8:46 AM, Astakos said:

After a lot of testing what I spotted was that xLODGen, during generation, arbitrarily replaces some of the original *world.lod files in MO with its own that seem to be quite corrupted.

  On 5/13/2019 at 8:46 AM, Astakos said:

Which simply means that xLODGen copied the contents of its log file for the given world into the actual mannygfo.lod file in the lodsettings folder in MO !!!!

xLODGen does nothing of that sort.

 

This seems to be caused by a bug in the latest MO version. We noticed similar problems being caused by MO when using DynDOLOD.

 

None of  these issues happened with earlier MO versions. The way xLODGen/DynDOLOD work is the same since years.

Edited May 13, 2019 by sheson

[Astakos]

I see.

 

Yeah I have noticed the discussion going on that thread you quoted me but I didn't think that it was relevant.

 

Are the MO2 guys aware of this bug or should I post on their discord?

 

Thanks sheson!

[sheson]

  On 5/13/2019 at 10:03 AM, Astakos said:

I see.

 

Yeah I have noticed the discussion going on that thread you quoted me but I didn't think that it was relevant.

 

Are the MO2 guys aware of this bug or should I post on their discord?

 

Thanks sheson!

I have not seen anything or posted anything, because I haven't had this error happen myself. And I pretty much got all the alpha, betas and RC of the new MO in the past months too.

 

However, based on the information from your post, it seems there might be an issue with the executed program (xLODGen.exe) starting a child process (LODGen.exe/TexConv.exe) and piping back its console output.

It seems that return pipe is somehow redirected by the virtual file system into a file that is/was open for reading.

[Astakos]

Okie.

 

As a matter of fact I will download the latest MO2 dev build (2.2.1 Alpha Build 2) and test again...

If this bug still occurs then I will direct them to this thread.

[Astakos]

It happened again with the newest MO2 alpha build (2.2.1 Alpha 2).

 

I guess I will make the MO guys aware by linking them our discussion sheson.

[sheson]

  On 5/13/2019 at 1:45 PM, Astakos said:

It happened again with the newest MO2 alpha build (2.2.1 Alpha 2).

 

I guess I will make the MO guys aware by linking them our discussion sheson.

Can you test with version 43? It uses a a different library to run the external commands. It is also compiled with latest Delphi version and has some additional multithreading optimizations. Maybe it makes a difference.

Edited May 14, 2019 by sheson

[Astakos]

Will do. Need at least 2-3 hours for my entire mod list.

[Astakos]

Hi sheson,

 

It seems that the version you uploaded above works just fine!

 

Tested it with MO2 version 2.2.1 Alpha Build 2.

 

Thanks a lot man! 

[sheson]

  On 5/13/2019 at 5:50 PM, Astakos said:

Hi sheson,

 

It seems that the version you uploaded above works just fine!

 

Tested it with MO2 version 2.2.1 Alpha Build 2.

 

Thanks a lot man! 

That's promising. A few more complete runs to double check ... :)

[El_Rizzo]

So correct me if my understanding of xLODGen is wrong here, but when I run xLODGen to generate object LOD, it should generate object LOD based on my currently active, personal load order, correct? I'm asking because I can't seem to get xLODGen to generate the correct LOD atlas for my current Fallout 4 load order. The specific mod I'm having issues with is Boston Natural Surroundings (BNS) and NeuralLOD. Since I'm using BNS I can't use the pre-built LOD files that NeuralLOD comes with, but have to generate my own using the resource file it alternatively provides for such cases. However, when I run xLODGen to generate new object LOD with both mods active (as well as the rest of my load order, of course), then the resulting atlas doesn't contain the green tree lod from BNS but instead the vanilla tree LOD.

 

This is what the atlas looks like that comes with BNS:

 

and this is the one that xLODGen creates based on my currently active mods:

 

I've also noticed that the generated LOD .bto meshes don't contain the trees that BNS adds to the game, unlike the files that come with BNS. I've tried with BNS's own LOD files present it its archives and I also ran xLODGen after manually deleting all the LOD files that came with BNS and the result was the same in both cases. I've used xLODGen 43 and the latest dev build of MO2, but other versions of both tools get the same result.

 

So my question is basically, is this working as intended and xLODGen simply doesn't consider mod added/changed objects during object LOD generation or is something going wrong on my end?