116 replies to this topic

[sheson]

FO4LODGen by Ehamloptiran, Zilav and Sheson
Static objects LOD generator tool for Fallout 4

 

After one and a half years, Zilav and I finally managed to incorporate FO4LODGen fully into the latest xEdit.exe builds posted to WIPz TES5Edit on Afk mods.

 

However, get the latest xLODGen - beta with terrain LOD, this is were the most recent LOD development happens.

 

Users of xEdit and FO3LODGen/FNVLODGen/TES5LODGen/SSELODGen will feel right at home.

After downloading and extracting the archive rename executable to FO4LODGen.exe or FO4LODGenx64.exe

Start FO4LODGen.exe with the command line parameter -o:"c:\Output" to set the output folder. This will make it easier to create BA2 archives, to avoid blurry textures because of loose texture files. I assume Fallout 4 modders know all about this issue with loose texture files, the involved INI settings and ENBoost.



Hover over the options of the FO4LODGen window to see hints what each setting does. If a texture atlas is not created it will use the vanilla texture atlas (Commonwealth and SanctuaryHillsWorld are supported atm, ping me if DLC worldspaces are required) if possible and single LOD textures if not.

I created a FO4LODGen Resources archive, to improve the generated LOD. While it is not required to generate object LOD, I recommend using the FO4LODGen.esp and the FO4LODGen - Main.ba2 for better results. Refer to the included docs/ReadMe.txt file to learn what each of the plugins do.
The plugins can be merged, but make sure to keep a the name FO4LODGen.esp in the load order so that the FO4LODGen - Main.ba2 is loaded when starting FO4LODGen.exe. Check the log to make sure the BA2 is loaded.

There is no hard requirement for the plugins that define unused LOD models and the FO4LODGen - Main.ba2 to be loaded in the game. However, if you notice flickering LOD textures or other odd behavior keep them in the load order. Let us know if this happened so we can update the instructions.

The FO4LODGen-DLCCoast-WindTurbines.esp is just a bonus plugin and has nothing to do with LOD generation.

All tree LOD in Fallout 4 is done as static LOD, so no billboards are required.

Even without the FO4LODGen Resources and no plugins changing the worldspaces, FO4LODGen already improves vanilla LOD. Tree LOD models use a feature called "double sided", which the vanilla LOD does not support. In vanilla this means the opposite side of branches are invisible. See below screenshots.

Please test and post results so we can work out any kinks before official release.
 



"Use backlight power"

Edited by sheson, 08 August 2019 - 01:12 AM.

[TechAngel85]

I'm sorry. You're going to had to stop. All of the firstborns have already been sacrificed.

[El_Rizzo]

Not sure if I somehow screwed up LOD generation, screwed up otherwise or if something is wrong with FO4LODgen but I noticed that when I load the generated files (packed into ba2s of course) along with the esps and FO4LODGen - Main.ba2 from the provided resources that some textures suddenly become really blurry when I approach an object and only after closing in further the correct textures are being loaded again. This does not happen without the generated LOD files active and the correct textures are being loaded even at a distance.

 

Here is an example of what I mean, when I fast travel to this location (Tenpines Bluff) the green steel beam textures for the bridge are relatively sharp at a distance , but once I get a little closer they become very blurry and low resolution all of a sudden as you can see here:

 

At a distance:  closer up:

 

 

Only when I get even closer it finally loads the textures that were present on the middle section of the bridge the entire time. Any idea what might be going wrong here? I've ran the LOD generation multiple times without different results. This effect is reproducible each time I load the game and go to this location (haven't tried others yet) and doesn't occur without the generated LOD files. My gpu's Vram is 6GB (GTX 980ti) and as you can see in the screenshots, it isn't full yet and there wasn't any more loading going on when I took them.

 

I initially ran FO4LODGen with default values (4096x4096 Atlas size, 100 Alpha, 512 max texture size, 1.1 uv and default compression settings, nothing else checked) but even changing atlas size up to 8192x8192 and max texture size to 1024 didn't change anything. Any ideas?

 

Also, what INI settings do you mean here? I know about the issue with loose texture files and what ENBoost is and how to use it, just not sure what specific INI settings you are referring to here:

 

I assume Fallout 4 modders know all about this issue with loose texture files, the involved INI settings and ENBoost.

I hope I've given all relevant information, if not I'm more than happy to provide them of course and I hope you guys can help me solve this problem :).

Edited by El_Rizzo, 29 January 2018 - 06:39 PM.

[sheson]

Do not forget to remove the loose files after packing them into a BA2.

If you packed all atlas textures into a BA2 and still got this, it could be that the blurry texture(s) are not on the atlas but used directly and probably loose. You would need to check the BTO in nifskope for this.

AFAIK the INI settings related to this problem are bForceUpdateDiffuseOnly, iTextureUpgradeDistance0/1 and iTextureDegradeDistance0/1. In case ENB is used verify ENB memory settings are correct. There are a lot of posts for Fallout 4 and blurry textures discussing all the options.

[El_Rizzo]

 

Do not forget to remove the loose files after packing them into a BA2.

I did, the output files were generated into an entirely different folder than my mods directory and I moved the 2 created BA2s (main and textures) into the mod folder manually and I made sure that they are loaded dead last (all my big texture mods are packed into BA2s).

 

 

If you packed all atlas textures into a BA2 and still got this, it could be that the blurry texture(s) are not on the atlas but used directly and probably loose. You would need to check the BTO in nifskope for this.

Like I said, all my big texture mods are packed into BA2s and I made sure that the esp loading the Lodgen output files is loaded dead last. The only texture mods with loose files are very specific and small ones, none of which have anything to do with landscape, bridges or buildings, I double checked that already :). But how would I go about finding the corresponding BTO file? Or will I simply have to open each one until I find the right one? :D

 

 

AFAIK the INI settings related to this problem are bForceUpdateDiffuseOnly, iTextureUpgradeDistance0/1 and iTextureDegradeDistance0/1. In case ENB is used verify ENB memory settings are correct. There are a lot of posts for Fallout 4 and blurry textures discussing all the options.

Alright, I knew about those before, I thought this referred to some INI tweak specifically for Fo4LODgen.

Edited by El_Rizzo, 30 January 2018 - 02:03 PM.

[sheson]

This is a general Fallout4 problem with lots of discussions about it. I am not spending much time with FO4. When I did vanilla game tests with no other mods (meaning no physical texture folder) and putting the LOD atlas textures into BA2 it fixed for me.

Use player.getpos x and player.getpos y in console and divide by 4096. That will give you the cell coordinates of the area. BTOs have their LOD level (number of cells in one direction) and lower left cell coordiantes in their file name.

If all fails, you can try not create an atlas when generating Commonwealth/Sanctuary to see if it makes a difference. It will then use the vanilla atlas. I haven't created the default mapping for other worldspaces yet.

Alternatively remove all mipmaps from the atlas texture.

Edited by sheson, 30 January 2018 - 06:15 PM.

[El_Rizzo]

 

This is a general Fallout4 problem with lots of discussions about it. I am not spending much time with FO4. When I did vanilla game tests with no other mods (meaning no physical texture folder) and putting the LOD atlas textures into BA2 it fixed for me.

Wouldn't be the first time Bethesda screwed something up regarding LOD The thing is, without using Fo4Lodgen or even with just the content from your provided resources, this blurry LOD does not occur and LOD is just fine. It is of course missing the Objects added by the generated files, but the LOD that is there doesn't get blurry, only when I use the generated files. I do use texture mods that replace the textures used for bridges, but FO4LODgen should read them, or am I mistaken?

 

But I'll try your suggestions and will report back with my results, thanks for your reply and suggestions, much appreciated! :)

[El_Rizzo]

Alright, so without creating an Atlas it works as intended, the new Objects/improved LOD Objects show up and it looks like this:

 

Before:

After:

 

 

What I noticed is the texture resolution when I also generate a texture atlas along with the LOD objects, without the atlas the textures look like this:

 

 

When I also create a texture atlas during generation it gets blurry and looks like this:

 

 

 

So apparently texture atlas creation generates really low res textures that are lower quality than the vanilla ones, is there any setting to change the quality of the textures? I've already tried setting the atlas size to 8192x8192 and max texture size to 1024 with the same results. I've made sure that there are no loose files causing it, so I've really got no clue what is going wrong here :(

Edited by El_Rizzo, 02 February 2018 - 07:56 PM.

[sheson]

So apparently texture atlas creation generates really low res textures that are lower quality than the vanilla ones.

That is not what is happening. LOD textures are not resized when put on the atlas.

The HWOverpassLOD_d.DDS is 256x256, so makes it onto the atlas textures regardless of what "Max texture size" drop down is set to. The "Atlas size" does not matter either. Lower sizes only mean it might create more than one atlas texture.

I already explained what is happening. It is caused by loose files, (default) INI or ENB settings or whatever.

If I remember right, removing the mipmaps from the textures can be used as a workaround. Then there are no lower resolution mipmaps the game can accidentally fall back to.

Edited by sheson, 02 February 2018 - 09:57 PM.

[El_Rizzo]

 

That is not what is happening. LOD textures are not resized when put on the atlas.

Okay, good to know, was just an uninformed speculation on my part :)

 

 

The HWOverpassLOD_d.DDS is 256x256, so makes it onto the atlas textures regardless of what "Max texture size" drop down is set to. The "Atlas size" does not matter either. Lower sizes only mean it might create more than one atlas texture.

I assumed that was the case but since I'm a layman when it comes to LODs I was just trying different settings to see if there is any change. Just out of curiosity, is there any downside or maybe even upside to having more than one texture atlas in general?

 

I already explained what is happening. It is caused by loose files, (default) INI or ENB settings or whatever.

 

 

But I don't have any loose files that could cause it ... all the mods that contain textures affecting anything in those screenshots are packed into BA2s. I even went ahead and packed every last small mod that had any loose files left into BA2s even though those only contained textures for completely different things (eyes, super mutants etc.) and even after making sure that I have absolutely zero loose files left (I mean it, zero), the results were the same. My data folder is also squeaky clean since I'm using Mod Organizer 2 for Fallout 4 (and ran Fo4LODgen through it ofc.), so there aren't any lingering files in there either (I manually checked as well of course).

 

As for INI settings and ENB, I don't use ENB for Fallout 4 and there are no leftovers of it either and my INIs are properly set up, I have bForceUpdateDiffuseOnly= set to 0 and increased the values of iTextureUpgradeDistance1= ,iTextureUpgradeDistance0= , iTextureDegradeDistance1= and iTextureDegradeDistance0= according to the numerous suggestions on the topic like this one and the result was exactly the same and I know the ini settings were applied because the Vram usage increased by over 1GB with those values.

 

Furthermore, I even generated LOD with all my mods disabled and only the vanilla and official DLC files active + your resources files and when I load the game (still only with vanilla + Fo4LODgen related files active) with the generated output files packed into BA2s of course and loaded by one of the ESPs from resources, the result was still the same. So even with no possibility of mods interfering and properly set up INIs I get the super blurry LOD textures with a generated atlas.

 

I would be more than happy if the issue is on my end so I can fix it, but I don't see how that is the case after all the different scenarios I've ran and the fact that it even happens with vanilla only files .

Edited by El_Rizzo, 03 February 2018 - 03:10 PM.

[sheson]

The downside of more than one atlas are additional draw calls. It is usually negligible in this context.

The BA2 you are creating may have the wrong settings or options. It needs to be "DDS" format and only contain Textures. Maybe compression plays a role. Find and follow a guide how to pack textures.

Maybe not adding Textures\ to sResourceDataDirsFinal helps.

The texture format should not matter. The vanilla game use DXT1 or DXT5 for diffuse and ATI2 for normal/specular. You could also try if BC7 makes a difference, but would have to use an external tool to convert.

Removing the mipmaps from the atlas texture should work in any case and is probably the best option at this point.

Edited by sheson, 03 February 2018 - 05:15 PM.

[El_Rizzo]

 

The downside of more than one atlas are additional draw calls. It is usually negligible in this context.

Good to know, thanks for the explanation! :)

 

 

The BA2 you are creating may have the wrong settings or options. It needs to be "DDS" format and only contain Textures. Maybe compression plays a role. Find and follow a guide how to pack textures.

I've read guides on how to create BA2s before, since I packed all my mods into BA2 files ;) and yeah, I selected DDS format and only the Atlas textures are in it, the meshes are in a separate BA2 with "general" as the format. I left compression for both BA2s at default and didn't touch any of the other settings as the guides recommended to leave them alone. I will try without compression for the textures BA2 and will report if that by chance solves it.

 

 

Maybe not adding Textures\ to sResourceDataDirsFinal helps.

I didn't add them to sResourceDataDirsFinal, I load the 2 BA2s via an esp (all following the naming convention for BA2s ofc) and placed it dead last in my loadorder to make sure it doesn't get overwritten.

 

Removing the mipmaps from the atlas texture should work in any case and is probably the best option at this point.

 

 

I would certainly like to try this, but have no idea how to do that :P Do you happen to have a tutorial at hand on how to remove mipmaps from the texture atlas? I don't have photoshop, but I do have GIMP with the necessary DDS plugins and also paint.net.

[sheson]

I would certainly like to try this, but have no idea how to do that :P Do you happen to have a tutorial at hand on how to remove mipmaps from the texture atlas? I don't have photoshop, but I do have GIMP with the necessary DDS plugins and also paint.net.

The GIMP save dialog for DDS should have an option to generate/not generate Mipmaps. So load texture in GIMP and then save with the Mipmap option disabled.

[El_Rizzo]

Yeah I figured it out myself by loading the texture into GIMP and messing around, but thanks for the fast response and help! and yeah that worked, as you predicted. Also, it seems the game really doesn't like uncompressed texture BA2s, when I created an uncompressed BA2 for the atlas textures (DDS format selected ofc.) it simply would make all LOD invisible and parts of the bridge were popping in as I moved closer even B.A.E. crashed when trying to extract it, so that isn't an option.

 

Thank you so much for patiently helping me with this issue! Still weird why it happened in the first place though

 

Oh and just in case you don't check that thread so often, I also have the issue with Fallout4 - Voices.ba2 mentioned here on the AFK forums, I have to move it out of the data folder if I wanna run FO4LODgen otherwise it crashes on me each time and my game language is English, both text and voice in case it is relevant.

Edited by El_Rizzo, 09 February 2018 - 04:14 PM.

[sheson]

Oh and just in case you don't check that thread so often, I also have the issue with Fallout4 - Voices.ba2 mentioned here on the AFK forums, I have to move it out of the data folder if I wanna run FO4LODgen otherwise it crashes on me each time and my game language is English, both text and voice in case it is relevant.

If you have the time, what is the timestamp and exact size in bytes of your Fallout4 - Voices.ba2?

You need to use a windows command prompt and the "dir" command or 3rd party file managers to get the exact bytes. Windows Explorer will always simplify the number.

Not that important, a next version of LODGen will just skip the file, since nothing useful for LOD is in there anyways.