Jump to content

Recommended Posts

Posted

Yes I'm using MO2, tried 2 different versions with the same result. OS preventing access does seem very unlikely since these textures are stored in archives and the rest of the archive's content is apparently accessible, or can Windows block individual files within archives? Aside from that, recent builds of MO2 are specifically checking all mod files for access when a 3rd party program is being run through it and fix any issues that arise. As for Antivirus, I'm only using the integrated Windows Defender and I specifically excluded my MO2 as well as my game and xLODGen directories.

 

No, with purely vanilla textures it doesn't happen. My main issue isn't that there are 5 normal maps that apparently can't be read, but that when I remove the 5 files in question that suddenly a whole bunch of new errors appear that weren't there before, which strikes me as rather strange. I can provide you with the 5 initial files and from which mods they came from if you want to take a look at them.

 

Yeah that explains why I don't get errors when de-selecting bake normals, makes sense.

 

Thx, good to know! :)

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

Posted (edited)

As I said, no version of xLODGen removes vertex colors from a LOD model unless No Vertex Colors is set in the options (dontGenerateVertexColors command line argument for LODGen.exe) or 

GenerateVertexColors=false or GenerateVertexColorsLOD[4|8|16|32]=false is set in the export file. The log from LODGen.exe says what the setting is. In case all of a LOD models vertex colors are white anyways they are removed for optimization.

 

Typically all the vanilla LOD models for LOD level are 8 are the ones ending with meshes\lod\mountains\*_lod_1.nif.

None of these vanilla LOD models have vertex colors other than all white. All of these vanilla LOD models use (mostly pre-rendered) LOD textures unlike the LOD 4 models (typically ending in *_lod_0[h|l].nif) which have vertex colors other than full white and use the same mountainslab texture as the full models.

I know this and much more (don't look at my new profile). Just see (3.1.2 vs 4.0.1, Falskaar gen for speed):

for example https://dropmefiles.com/CQtBC (in archive you found 2 version objects gen. (312/401) and custom mountains lod meshes)

all created on clear game (LE).

2aeca76eea87a6ee6fb03907da858c5a.jpg9171608c3fa0468ddafc26dde8a0c158.jpg

Edited by Mitradis
Posted (edited)

I know this and much more (don't look at my new profile). Just see (3.1.2 vs 4.0.1, Falskaar gen for speed):

for example https://dropmefiles.com/CQtBC (in archive you found 2 version objects gen. (312/401) and custom mountains lod meshes)

all created on clear game (LE).

 

So I checked The file /401 Falskaar/Falskaar.8.0.16.bto and see that it the LOD mesh has vertex colors which unsurprisingly shows that they are not removed.

 

Looking at your screenshot there is one more setting that might be controlling vertex color. The base records for LOD models needs to have "HD LOD" flag set. Maybe something changed in regards to that flag or how it is overwritten in the export file.  Whatever I try here in regards to the HD flag though does not change that any tests I do always have vertex colors regardless of LOD level as long as the Generate Vertex Color  log entry says true.

Edited by sheson
Posted (edited)

Not Falskaar.8.0.16.bto see Falskaar.8.0.-16.bto

 

I installed the mountain LOD meshes from your archive. Generated LOD for Tamriel. All LOD levels and all mountains LOD meshes keep their vertex colors if they are not all white.

 

Now I also tested Falskaar and checked 8.0.-16 and both mountain meshes (there are 2 as far as I can tell) have vertex colors. No idea what else to test or what happens in in your case.

Edited by sheson
Posted (edited)

Thank. Where i can get info about format mesh block name?

c27d6c25292f255a1a8b6c18140c527b.jpg

as far as i understand it affects the generation. What should be the format for different models.

Edited by Mitradis
Posted (edited)

Thank. Where i can get info about format mesh block name?

c27d6c25292f255a1a8b6c18140c527b.jpg

as far as i understand it affects the generation. What should be the format for different models.

The following identifiers are recognized in the shape names: NoReUV, FixedNormals, SphereNormals. None of them should change vertex color behaviors. Since I tested with the LOD meshes from your archive they work fine as they are. You may want to try to reset xEdit LOD settings by starting by holding SHIFT or deleting the file config file c:\Users\[username]\AppData\Local\Skyrim\Plugins.tes5viewsettings

 

You can find LODGen.exe update notes in DynDOLODs changelog with the prefix LODGen.exe.

Edited by sheson
Posted (edited)

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 by sheson
Posted

 

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 ::P: ) 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

Posted

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.

Posted (edited)

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 by sheson
Posted (edited)

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 by Mitradis
Posted

 

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.

Posted (edited)

 

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 by sheson

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.