Jump to content

Recommended Posts

Posted (edited)

 

 

 

In TTW basic, the lines that stand out look like something minor.

https://imgur.com/IgziQ3X

If using NMC textures, the final stage shows many - textures not on atlas, some LOD will be missing in game!

 

 

 

 

Guess that is it, AFAIK - TTW LOD comes pre-generated and packed into .bsa

That was my fear, because there may be (many!) more of likewise cases, generating LOD for FO3 portion of TTW becomes a risky venture.

 

Not a xLODGen issue, but could you tell how does one find out these specific models?  :confusion:

For example, how to find out which specific model is missing for xLODGen to include the Water Tower in the atlas?

(Hopefully, if given a practical example, I can follow up from there)

 

 

Btw, I'm assuming each atlas are those images generated inside the folder \blocks

looks like a comprised-miniature index for LOD visuals

NMC textures comes with this image and theres a Water Tower in there, but in-game the Water Tower looks wrong once it gets in the LOD, as does some other stuff too.

https://imgur.com/a/0OmBXbu

 

Again, many thanks if you can take the time!

 

Instead of making screenshots of text, copy and paste the text to pastebin or upload the logile to a file service.

 

In FO3/FNV it is a simply file matching process. The LOD model for house.nif is house_lod.nif in the same folder.

 

Based on the wrong position error, it is possible that the LOD model is not read properly and missing because of that. This version of LODGen.exe should print a better message that also print the model filenames for easier troubleshooting. I might remember this wrong, but FO3/FNV object LOD typically has no vertex colors, but nevertheless LODGen should be able to read the nif.

 

The object LOD texture atlas is stitched together from the texture that are referenced in the LOD nif file - the single source texture.

LOD only has binary transparency and the default threshold is at 128. If transparency is messed up, then either something is off with the source texture or something happened to the LOD atlas texture. Best to use DXT1 with 1 bit transparency or DXT5 with alpha channel for source and atlas texture. 

Edited by sheson
Posted

This may be an inappropriate place to post this question and it may have already been answered somewhere else, but I'm struggling with xLODGen and haven't been able to find an answer anywhere else.

 

I'm following the most recent iteration of the TucoGuide over on Nexus (TucoGuide 3.4.3.0) and have pretty much followed everything in the guide to the letter. I have reached the portion where they guide us through the use of xLODGen and have run into an issue.

 

When I run SSELODGen, 90% of the functions return an error message. Those error messages look like this:

 

[04:46] <Warning: Error reading texture Textures\Landscape\ReachDirt01_N.dds>
[04:46] Error: Executing TexConv failure: "D:\Steam\steamapps\common\xLODGen\Edit Scripts\Texconvx64.exe" -nologo -y -f R32G32B32A32_FLOAT -o "C:\Users\[NAME]\AppData\Local\Temp\SSEEdit" "C:\Users\[NAME]\AppData\Local\Temp\SSEEdit\242B0E3ADB5D41F3B693026F6928C882.dds"
 
After two hours of runtime, SSELODGen finished and left me with about 10% of processes that didn't return these error messages. Does anyone have any idea of what could be causing the error messages or what I could do about them?
 
For what it's worth, <C:\> is my system drive and <D:\> is the drive where I keep SSE and MO2 and all mods.
 
Thanks in advance! :-D
Posted (edited)

This may be an inappropriate place to post this question and it may have already been answered somewhere else, but I'm struggling with xLODGen and haven't been able to find an answer anywhere else.

 

I'm following the most recent iteration of the TucoGuide over on Nexus (TucoGuide 3.4.3.0) and have pretty much followed everything in the guide to the letter. I have reached the portion where they guide us through the use of xLODGen and have run into an issue.

 

When I run SSELODGen, 90% of the functions return an error message. Those error messages look like this:

 

[04:46]

[04:46] Error: Executing TexConv failure: "D:\Steam\steamapps\common\xLODGen\Edit Scripts\Texconvx64.exe" -nologo -y -f R32G32B32A32_FLOAT -o "C:\Users\[NAME]\AppData\Local\Temp\SSEEdit" "C:\Users\[NAME]\AppData\Local\Temp\SSEEdit\242B0E3ADB5D41F3B693026F6928C882.dds"

 

After two hours of runtime, SSELODGen finished and left me with about 10% of processes that didn't return these error messages. Does anyone have any idea of what could be causing the error messages or what I could do about them?

 

For what it's worth, is my system drive and is the drive where I keep SSE and MO2 and all mods.

 

Thanks in advance! :-D

Yes it came up before, but then there are other users who post screenshots of log messages instead of the text so searching for something becomes a bit more tedious...

 

Look at the answer I gave yesterday 3 posts up: https://forum.step-project.com/topic/13451-xlodgen-terrain-lod-beta-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal/page-48?p=238090&do=findComment&comment=238090

 

Do not install tools into Steam, game, mod manger or special OS folders like Program Files x86. Install tools into their own dedicated folders. Use the -o command line to output files into dedicated folders outside of Steam, game or mod manger folders.

Edited by sheson
Posted (edited)

Yes it came up before, but then there are other users who post screenshots of log messages instead of the text so searching for something becomes a bit more tedious...

 

Look at the answer I gave yesterday 3 posts up: https://forum.step-project.com/topic/13451-xlodgen-terrain-lod-beta-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal/page-48?p=238090&do=findComment&comment=238090

 

Do not install tools into Steam, game, mod manger or special OS folders like Program Files x86. Install tools into their own dedicated folders. Use the -o command line to output files into dedicated folders outside of Steam, game or mod manger folders.

Interesting effects to note:

 

1.) I ran SSELODGen through a command prompt as suggested. This time, the error messages each had to do with a VCRUNTUIME dll file and the percentage of errors dropped to 2%.

 

2.) I also ran the x86 version of SSELODGen through MO2. This returned zero errors.

 

3.) Neither of the above methods attempted to call .dds files that are being called when running the x64 version of SSELODGen through MO2.

 

This leads me to believe I have something installed in MO2 that is telling xLODGen to look for .dds files that don't actually exist.

 

More investigation is necessary. I'll report back if I make any discoveries.

Edited by ahrneely
Posted (edited)

Interesting effects to note:

 

1.) I ran SSELODGen through a command prompt as suggested. This time, the error messages each had to do with a VCRUNTUIME dll file and the percentage of errors dropped to 2%.

 

2.) I also ran the x86 version of SSELODGen through MO2. This returned zero errors.

 

3.) Neither of the above methods attempted to call .dds files that are being called when running the x64 version of SSELODGen through MO2.

 

This leads me to believe I have something installed in MO2 that is telling xLODGen to look for .dds files that don't actually exist.

 

More investigation is necessary. I'll report back if I make any discoveries.

The suggestion is to run TexConv on the command prompt to see if there are messages about missing requirements.

 

If the x86 version works, it probably means the x86 version of the required Rredistributable is installed, but the x64 version is not.

 

Not sure how you would know what textures TexConv needs to convert if there is no error, since there is no message if it just works.

Edited by sheson
Posted

 

Not sure how you would know what textures TexConv needs to convert if there is no error, since there is no message if it just works.

I'm not quite sure I understand. Does this mean that if no error message appears the log wouldn't display the .dds file of the texture it's trying to convert? Therefore, my assumption that the x86 version "not calling a .dds" that the x64 version errors out on is invalid? (Which, by the way, is cool. As long as something is working, I guess I don't care how it works.)

Posted (edited)

I'm not quite sure I understand. Does this mean that if no error message appears the log wouldn't display the .dds file of the texture it's trying to convert? Therefore, my assumption that the x86 version "not calling a .dds" that the x64 version errors out on is invalid? (Which, by the way, is cool. As long as something is working, I guess I don't care how it works.)

When generating LOD, TexConv may convert 10000s of textures. When everything works as planed you won't see a single log line about TexConv doings its thing in the background.

 

If the error message would be about missing texture it would be obvious from the message and I would have suggested a troubleshooting step into that direction.

 

Run TexConv.exe/TexConvx64.exe from the command prompt to see if it tells you what might be wrong.

Edited by sheson
Posted

12.7 GB just for terrain LOD (1k defuse and 512 normals BC7 both)... It's like installing another game!

1024x1024 is 16 times the pixels of a vanilla terrain LOD texture with 256x256.

Posted

The size went up from 12.7 GB to 17.8 GB when I used the newer xLODGen beta version and I've decreased the defuse size also to 512

Posted

The size went up from 12.7 GB to 17.8 GB when I used the newer xLODGen beta version and I've decreased the defuse size also to 512

I am still not sure what you are trying to say. Do you have a question or is this some kind of problem report that just lacks information?

Posted

I am still not sure what you are trying to say. Do you have a question or is this some kind of problem report that just lacks information?

Yes I'm just wondering why the size went up when I decreased the defuse from 1024 to 512 especially after updating xLODGen to the latest version... The previous size were from a previous xLODGen version... Does it supposed to be lower or the same at least?

Posted

Yes I'm just wondering why the size went up when I decreased the defuse from 1024 to 512 especially after updating xLODGen to the latest version... The previous size were from a previous xLODGen version... Does it supposed to be lower or the same at least?

Check if the compression of all files is the same/desired one. Make sure to use the latest xLODGen version.

Posted

Check if the compression of all files is the same/desired one. Make sure to use the latest xLODGen version.

They were the same BC7 before and after for both generations

Posted (edited)

They were the same BC7 before and after for both generations

All you have to do is to compare the two outputs to find the difference.

 

Is it the same amount of files? Do they have the same mip map settings? Is the default size the same? Which ones are larger in file size than before?

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.