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

[sheson]

i no have idea. Where i get source code LODGen.exe? Only this take me answer.

Use the older version for object LOD generation if it does what you need until I have time to check a few ore things and see if I can replicate or find out what it is.

 

Edit: If you have a chance send me the custom LOD textures mountainslablod2.dds/mountainslablod3.dds as well.

Why were some of the vanilla LOD level 4 meshes changed to use mountainslablod.dds instead of the correct textures\landscape\mountains\MountainSlab02.dds?

Why do the new higher LOD levels uses different LOD textures? It seems they should be using the same texture as LOD Level 4.

That doesn't make any sense. All meshes have matching UVs that can not be atlassed anyways. All those meshes should use the full texture for best performance and visuals.

 

That way they loose their HD flag. Typically only HD LODs that do not use lod textures keep their vertex colors in the higher LOD levels.

Edited January 19, 2019 by sheson

[El_Rizzo]

 

Please send me one version of each different format. So if they all using the same format, one example should be enough.

Not sure what you mean by "one version of each different format", but I uploaded the 6 (forgot one yesterday when I said 5, derp ) normals that were causing the initial errors, hope that is what you meant, if I misunderstood you, please let me know. Here you go: https://www46.zippyshare.com/v/IvpzDQHe/file.html

 

The mods that these files come from are:

Rubbles and Trashpiles HD

Quarry HD

Vivid Fallout All-in-One

Fo4 Landscape Overhaul HD

[Mitradis]

Why were some of the vanilla LOD level 4 meshes changed to use mountainslablod.dds instead of the correct textures\landscape\mountains\MountainSlab02.dds?

i switched lod textures for rocks\mountains on low res texture for less memory use. For each level texture/2 resolution, no bad visual effect. Other i send in PM.

[sheson]

i switched lod textures for rocks\mountains on low res texture for less memory use. For each level texture/2 resolution, no bad visual effect. Other i send in PM.

The full mountainslab texture is already loaded because it is more or less used in every loaded cell anyways. All textures typically have mipmaps, so there is no need to have the same texture with different resolution.

 

I believe what is happening is that these particular meshes/texture combination runs into CK compatibility and performance optimizations I added to LODGen.exe. A vanilla LOD convention is that only HD LODs which are using full texture have vertex colors, while meshes using lod textures have not (since often they are pre-rendered). A problem with vertex colors is that the snow/ash shaders pick them up, so they have limited use.

 

There are options/filters/exceptions that can be set (which DynDOLOD uses to automate things for itself). You should be able to to set them manually, I will have to verify the combination and config settings. I should have an update some time tomorrow hopefully.

Edited January 19, 2019 by sheson

[Mitradis]

Here original vanilla meshe with added\replace on not white vertex colors. And result same. Textures not a cause.

https://dropmefiles.com/DukXV

don't leave the main thing: we have 3.1.2 version in which these problems are greatly reduced, after 3.2.1 problems are increasing. I take LODGen.exe from 321 in 312 version and have same problem with colors. Problem in LODGen.exe.

Edited January 19, 2019 by Mitradis

[sheson]

 

Textures not a cause.

 

The fact that only LOD textures have "lod" in their name is used for automatic logic so we do not have to rely on the HD LOD on base records in plugins to get it do things we need. But as mentioned there are settings to control that behavior, just need to manually set them and see if they are sufficient for this case.

[sheson]

 

Here original vanilla meshe with added\replace on not white vertex colors. And result same. Textures not a cause.

https://dropmefiles.com/DukXV

don't leave the main thing: we have 3.1.2 version in which these problems are greatly reduced, after 3.2.1 problems are increasing. I take LODGen.exe from 321 in 312 version and have same problem with colors. Problem in LODGen.exe.

 

 

Get the latest 0.38 from first post. It will allow overwriting the default options properly in all cases (that I tested).

 

Since you have custom LOD texture instead of the default HD LOD texture mountainslab02.dds you will have to create an options file for each worldspace were you want to have HD LOD with vertex colors in the higher LOD levels.

You can see path/filename of the options file it tries to load from the log by looking for "No options file found: ..."

The format is ..\Edit Scripts\[Game Mode]LODGen_[Pluginname that adds the worldspace]_[worldspace name]_Options.txt

So for Falskaar it is "..\Edit Scripts\TES5LODGen_Falskaar_Falskaar_Options.txt"

 

In this case add the lines to the file

IsHDTextureMask=mountainslablod.dds

IsHDTextureMask=mountainslablod2.dds

IsHDTextureMask=mountainslablod3.dds

 

Any shape in any NIF using these textures will be treated has HD LOD, that will keep vertex colors.

 

However, as already mentioned it would be better for performance, resource usage and visuals to keep the original and default HD texture MountainSlab02.dds texture on all the custom LOD NIFs.

That one does not need to be added to the options file as it typically is already set in the export file for TextureDiffuseHD=. It should keep vertex colors by default.

Edited January 20, 2019 by sheson

[Mitradis]

Awesome Thank you very much!

[El_Rizzo]

@Sheson

 

Did you have a chance to look at the normals I uploaded for you? Did you find anything unusual with them?

[sheson]

@Sheson

 

Did you have a chance to look at the normals I uploaded for you? Did you find anything unusual with them?

I just tested. They work fine here. They are in unusual formats for FO4 normals which are usually 2 channel BC5 so not sure what the reason is for that.

 

Because of that some require the use of TexConv.exe to load, which means a temp version is created first, then converted externally by texconv and then read. That is where UAC, antivirus, disk full error could interfere. 

 

You tried them as loose file to rule out BSA reading errors right?

 

No idea why removing them would cause other textures to have problems. Since you seem to be using xLODGenx64 it shouldn't be running out of memory either. But maybe see if only selecting build normal and smaller sizes like 128 make a difference.

Edited January 20, 2019 by sheson

[El_Rizzo]

 

But maybe see if only selecting build normal and smaller sizes like 128 make a difference.

I already tried with size 32 for diffuse and normals for all levels and mesh quality 30 to speed up the process and get to the warnings faster and the result was the same.

 

 

You tried them as loose file to rule out BSA reading errors right?

Yes, I extracted the 5 files and that is when suddenly other warnings cropped up. I'll try with just loose files to see if that gets a different result and report back to you.

[El_Rizzo]

Alright, so I have some interesting observations to make. First of all, there were no errors when I ran xLODGen using loose files, so the files themselves seem to be okay (as you had confirmed on your end as well).

 

Secondly and more interestingly, when I extracted the four BA2 archives with B.A.E. (latest Fo4 version) I got this error message while extracting Vivid Fallout:

 

 

 

As you can see it is mostly normal maps that are causing issues, including two of the ones that I sent you (marshmuddygrass01_n and marshmudfloor01_n). I re-downloaded the mod (4k version) and got the same errors with the freshly downloaded one as well. Interestingly enough, the official archive2.exe from the Fo4 CK has no problems extracting the archives and no files are missing unlike with B.A.E. I also manually created an archive from the extracted files (the ones extracted with archive2 of course, since the one from B.A.E. were missing files) with archive2.exe (DDS format, default compression, rest on default) and B.A.E. had the same errors with this archive.

 

So I assume that there is some issue with how these archives are being read by xLODGen the same way that B.A.E. has issues?

[sheson]

Alright, so I have some interesting observations to make. First of all, there were no errors when I ran xLODGen using loose files, so the files themselves seem to be okay (as you had confirmed on your end as well).

 

Secondly and more interestingly, when I extracted the four BA2 archives with B.A.E. (latest Fo4 version) I got this error message while extracting Vivid Fallout:

 

 

 

As you can see it is mostly normal maps that are causing issues, including two of the ones that I sent you (marshmuddygrass01_n and marshmudfloor01_n). I re-downloaded the mod (4k version) and got the same errors with the freshly downloaded one as well. Interestingly enough, the official archive2.exe from the Fo4 CK has no problems extracting the archives and no files are missing unlike with B.A.E. I also manually created an archive from the extracted files (the ones extracted with archive2 of course, since the one from B.A.E. were missing files) with archive2.exe (DDS format, default compression, rest on default) and B.A.E. had the same errors with this archive.

 

So I assume that there is some issue with how these archives are being read by xLODGen the same way that B.A.E. has issues?

Can BAE unpack the vanilla archives without problems?

 

Can you test extraction with xEdit 4.0.1? It will load the BA2 via the normal plugin name. Then start Asset Browser with CTRL+F3 and enter part of those file names in the filter, then right click one of the found files to extract.

[El_Rizzo]

Can BAE unpack the vanilla archives without problems?

 

Yes, it has no problems with vanilla archives and most mod archives either, tho I had issues with it with Fallout 4 archives before, but it was an older version which just crashed instead of giving an error message.

 

Can you test extraction with xEdit 4.0.1? It will load the BA2 via the normal plugin name. Then start Asset Browser with CTRL+F3 and enter part of those file names in the filter, then right click one of the found files to extract.

 

xEdit is able to extract the files, however!, it makes them unreadable in the process. I extracted marshmuddygrass01_n from Vivid Fallout once with xEdit and once with archive2.exe and while I can open and view the version I extracted with archive2, the file from xEdit cannot be opened by the same program, in my case it was paint.net with up to date dds plugin. I tested with other files that caused errors in B.A.E. and the same thing happened there as well. So it seems xEdit and by extension xLODGen has a problem extracting these files or reading the archive correctly, right?

Edited January 21, 2019 by El_Rizzo

[sheson]

Yes, it has no problems with vanilla archives and most mod archives either, tho I had issues with it with Fallout 4 archives before, but it was an older version which just crashed instead of giving an error message.

 

xEdit is able to extract the files, however!, it makes them unreadable in the process. I extracted marshmuddygrass01_n from Vivid Fallout once with xEdit and once with archive2.exe and while I can open and view the version I extracted with archive2, the file from xEdit cannot be opened by the same program, in my case it was paint.net with up to date dds plugin. I tested with other files that caused errors in B.A.E. and the same thing happened there as well. So it seems xEdit and by extension xLODGen has a problem extracting these files or reading the archive correctly, right?

Yes, I will check with the other xEdit devs about this. There already was talked about updating the BSA functions anyways.

 

To be clear, xEdit and xLODGen are just different modes of the same application. The xLODGen Terrain LOD beta just has changes in the LOD and Image lib parts for testing before they finally merge back into the official version.