FO4LODGen

[SpaceMad]

What is not working when you set a dedicated output path? I suggest to always generate to an empty dedicated folder to avoid overwriting existing files in the data folder. Then create archive from there.

Yes, when I set a dedicated output path the LODs won't show up, of course I copied them over to the right folders. So yeah, I have to generate to the main game folder or it won't show up. Beta 9 maybe fixed that, but I have just used it without an output path. Have 3 different version installed allready. So not sure what version it was, but it wasn't beta 9.

 

Typically either the LOD meshes/textures work or they don't. If a problem is not 100% repeatable it most likely has an unrelated cause.

Sorry for not beeing completely clear with my spelling. It's 100% repeatable and I'm absolutely sure it's the LOD. As I've said it has been a very long bug hunt. I've deactivated everything, even reinstalled the whole game. Fresh game, new character to be sure it's not a savegame related error. I had only LODs. It crashed. But after I removed the terrain folders everything worked fine. No CTD whatever I do. I couldn't imagine the LODs to be the issue, so naturally it has been the last I've removed and even reinstalled the whole game, before doing it. I reapplied all my mods, loaded up the savegame. Everything fine, no CTD at all. I put back the LODs, and there it crashed again. I then regenerated a few times with various settings. Not fixed. The game does a quick save before it crashes. And that save can be loaded and it is not corrupted. I won't use them, but just saying. Sometimes it does not CTD directly, but 1 or 2 seconds after the loading screen, thats what I meant with allmost.

 

Especially, it should not matter from where or how the got to a location, either be it by walking, exiting an interior or fast traveling from afar.

And thats an other freaky point. It actually does. Porting into the commonwealth (worldspace) or any interior that's connected with the commonwealth will load up fine. I've tested that several times with different locations. Vanilla good neighbor with it's empty cells and 5 actors just won't. Diamond city and Goodneighbour are using the atlas and meshes from the commonwealth, but without having an own (unique) LOD. I can't get rid of the feeling that it has something to do with this child/parent setup.

 

It could be a resource problem for example - though that seems a unlikely with the 64 bit engine, maybe VRAM limits, not sure I have not spend much time with FO4 or modding it.

Very unlikely with my setup, either. I rarely have CTD anywhere, and I've allways try to max out the graphics of beth games as far as I can. I've been a bit impressed how much the engine has been improved in terms of stability. I can play it for hours and it won't crash at all. Even with maxed out ENB stuttering and FPS drops are very rare with fixed vis data & occlusion culling planes. In the 60 hours of my current playthrough with tons and tons of mods the game crashed 2 times. It can't be a resource issue. Vanilla Goodneighbour is really empty and leaves gigs of VRAM unused as it demands not much at all. But who knows, maybe there is something wrong with bethesdas code.

 

The LOD files you uploaded work fine in my game entering/exiting lots of different buildings in Goodneighbour.

Damn, and here I hoped it would be something that can be easily fixed more or the less. I will try with beta 10 and just hold my fingers crossed. If not, well maybe I can send you the log files than.

Anyways, I'd rather deactivate the esp within cities, than not using the amazing & very noticeable visual quality improvement LODGen comes with. Happy they show up now, and hopefully that other error will be fixed as well.

Edited April 4, 2018 by SpaceMad

[sheson]

Yes, when I set a dedicated output path the LODs won't show up, of course I copied them over to the right folders. So yeah, I have to generate to the main game folder or it won't show up. Beta 9 maybe fixed that, but I have just used it without an output path. Have 3 different version installed allready. So not sure what version it was, but it wasn't beta 9.

The generated files are exactly the same regardless of the selected output folder. If they do not work in-game, they are not correctly installed.

 

Sorry for not beeing completely clear with my spelling. It's 100% repeatable and I'm absolutely sure it's the LOD. As I've said it has been a very long bug hunt. I've deactivated everything, even reinstalled the whole game. Fresh game, new character to be sure it's not a savegame related error. I had only LODs. It crashed. But after I removed the terrain folders everything worked fine. No CTD whatever I do.

The files you sent were esp and BSAs, so you mean that, right. One test to do would be to not pack them and then selectively remove the atlas textures and then chunks of BTO in order to see if only specific files cause a problem.

 

I've removed and even reinstalled the whole game, before doing it.

That can only "fix"things if files are outdated or there are still foreign files lingering around.

 

I reapplied all my mods, loaded up the savegame. Everything fine, no CTD at all. I put back the LODs, and there it crashed again.

The obvious first test would be to not install any mods, change any settings and then generate LOD for vanilla and see what happens.

 

I then regenerated a few times with various settings. Not fixed.

All of the xLODGen settings are equally safe to use. The only difference would textures sizes in terms of VRAM usage.

 

And thats an other freaky point. It actually does. Porting into the commonwealth (worldspace) or any interior that's connected with the commonwealth will load up fine. I've tested that several times with different locations. Vanilla good neighbor with it's empty cells and 5 actors just won't. Diamond city and Goodneighbour are using the atlas and meshes from the commonwealth, but without having an own (unique) LOD. I can't get rid of the feeling that it has something to do with this child/parent setup.

It does not matter how the player gets to a location, the same bto/dds files are loaded. It the problem should also happen when fast traveling into Goodneighbour from afar, or just going through the gate from the Commonwealth.

 

I will try with beta 10 and just hold my fingers crossed. If not, well maybe I can send you the log files than.

What mod manager are you using?

Edited April 4, 2018 by sheson

[Vos80]

First and foremost, thanks for this tool. The creation kit wouldn't let me generate LOD because the atlas would be bigger than 4096x2048, and this works fine.

 

But I've got the same problem as El_Rizzo: the LOD textures are quite blurry. Other than wanting to find a solution, I want to let you know that it is not an isolated problem and also present on XB1.

 

 

 

 

 

LOD in Far Harbor seems better for some reason:

 

 

The atlas is archived, since I ported it through the creation kit to XB1. Screenshots were taken on XB1 as well, my laptop has low specs and you wouldn't be able to tell if a high or low res texture was used anyway :p.

 

The atlas seems fine, here a comparison between the LOD dds and the atlas

 

 

All other textures in the mod work as they are supposed to do.

 

Could it be that it has something to do with the meshes that are generated? And since changing the INI file on XB1 isn't possible, is it possible to change setting during LOD object generation?

Or could it be that the standard LOD texture size of 4096x2048 has something to do with it?

 

[sheson]

The creation kit wouldn't let me generate LOD because the atlas would be bigger than 4096x2048, and this works fine.

Is there some kind of error message that you could post? I never really bothered to much with FO4 CK. Maybe this is a hint to the mipmap problem (e.g. blurry textures)

 

Is the Far Habour atlas texture smaller than 4096x2048?

 

If so set max atlas dimension for Commonwealth to 4096x2048 in the options. It will then create 2 atlas textures. See if that fixes it.

 

But I've got the same problem as El_Rizzo: the LOD textures are quite blurry. Other than wanting to find a solution, I want to let you know that it is not an isolated problem and also present on XB1.

 

If all else fails, just remove the mipmaps from the atlas textures as that seems to be the working solution in that case.

Edited April 4, 2018 by sheson

[Vos80]

Is there some kind of error message that you could post? I never really bothered to much with FO4 CK. Maybe this is a hint to the mipmap problem (e.g. blurry textures)

 

Is the Far Habour atlas texture smaller than 4096x2048?

 

If so set max atlas dimension for Commonwealth to 4096x2048 in the options. It will then create 2 atlas textures. See if that fixes it.

 

 

If all else fails, just remove the mipmaps from the atlas textures as that seems to be the working solution in that case.

Thanks for the quick response. The CK error says: "creation kit Atlas layout failed. This probably means the LOD for this world is using too much texture space (max total size is 4096 x 2048)."

 

This makes sense, because I could generate the LOD for SanctuaryWorld and Far Harbor, and both atlasses for those worlds fit on one textures of 4096 x 2048. Commonwealth and Nuka World need a bit more space than that.

 

I removed the mipmaps from the atlasses, but that doesn't seem to work either.

 

I did some more research, and it seems to be related to how the meshes are rendered. 

 

For example Elm LOD ingame:

 

Elm LOD in Nifscope (leaves are clearly visible):

 

 

Highway board ingame:

 

Highway board in Nifscope (more detailed texture as well):

 

 

Electric Tower ingame (or lack thereof):

 

 

Electric tower in Nifscope:

 

 

So the textures and alphas seem decent in Nifscope, but are of less quality ingame even without mipmaps. 

 

I might upload this version of the mod on Nexus to ask if other people experience it as well on their PC to determine if it is caused by system specs.

Edited April 4, 2018 by Vos80

[sheson]

I removed the mipmaps from the atlasses, but that doesn't seem to work either.

If this is not a mipmap problem then the only other setting that can influence the transparency of trees and that electric tower like in your screenshots is the alpha threshold. It may be possible that the console is not supporting the same flexibility as the PC version.

 

Check what the alpha threshold value is in the nifs.

 

You could try using the vanilla atlas by unchecking the generate atlas checkbox. This will only work with Commonwealth and Sanctuary atm as I didn't create vanilla atlas info for DLC worldpaces yet.

 

You could also try using DXT1 instead of DXT5 and lowering the alpha threshold, or use gimp to change the alpha channel directly.

Edited April 4, 2018 by sheson

[Vos80]

If this is not a mipmap problem then the only other setting that can influence the transparency of trees and that electric tower like in your screenshots is the alpha threshold. It may be possible that the console is not supporting the same flexibility as the PC version.

 

Check what the alpha threshold value is in the nifs.

 

You could try using the vanilla atlas by unchecking the generate atlas checkbox. This will only work with Commonwealth and Sanctuary atm as I didn't create vanilla atlas info for DLC worldpaces yet.

 

You could also try using DXT1 instead of DXT5 and lowering the alpha threshold, or use gimp to change the alpha channel directly.

I hadn't thought about checking the alpha in the nifs, I'm going to do that tommorow, thanks for the suggestion. Using the vanilla atlas is my last resort, because it will not include the textures of the new trees in the commonwealth. 

 

I've uploaded the file to the nexus, to see if the problem is due to system specs. I hope someone downloads the new version, and could give some feedback on that. This is not meant as a shameless plug, but if someone who reads this wants to try it out: https://www.nexusmods.com/fallout4/mods/29873

 

Thanks again for the advice and I will let you know once I figured out a solution. 

[sheson]

Using the vanilla atlas is my last resort, because it will not include the textures of the new trees in the commonwealth.

Correct, it will use the single texture for the ones that are not on the atlas, so it is not optimal for performance, but testing this hopefully helps us understanding this problem better.

[SpaceMad]

 

It the problem should also happen when fast traveling into Goodneighbour from afar, or just going through the gate from the Commonwealth.

As I said it crashed only in Goodneighbour and Diamond City. Dosn't matter where I get there. But it won't crash in the Commonwealth worldspace.

 

 

 

What mod manager are you using?

Does it matter? NMM and I allways check with FO4Edit.

 

You are right about the alpha! And whatever I do it stays like that on 0. I've tried to use the source values and also with the full model tree esp, but that made it even worse with no alpha at all.

[sheson]

You are right about the alpha! And whatever I do it stays like that on 0. I've tried to use the source values and also with the full model tree esp, but that made it even worse with no alpha at all.

Use xLODGen beta 11, that should fix Use source alpha threshold.

 

But for the case source alpha is not checked, can you check if ..\Edit Scripts\LODGen.txt contain a line DefaultAlphaThreshold=110 or whatever the value is you selected in the options?

 

Does it make a difference if using x86 or x64 version of xLODGen?

 

What is the installation path of xLODGen and the game?

 

What language is the OS you are using?

 

When you install new versions of xLODGen, completely remove the old installation first to make sure there are no old files lingering around.

 

Are the worldspace records for Goodneighbour or Diamond City changed by plugins?

Edited April 5, 2018 by sheson

[SpaceMad]

Use xLODGen beta 11, that should fix Use source alpha threshold.

 

But for the case source alpha is not checked, can you check if ..\Edit Scripts\LODGen.txt contain a line DefaultAlphaThreshold=110 or whatever the value is you selected in the options?

 

Sadly the alpha is not fixed for me.

Well, now the source alpha turns out as 0 as well. I have the line in the LODGen.txt (DefaultAlphaThreshold=110)

 

Does it make a difference if using x86 or x64 version of xLODGen?

What is the installation path of xLODGen and the game?

What language is the OS you are using?

No, it's the same with both 32 and 64bit version.

installation path of game = S:\Games\Fallout 4

installation path of xLODGen = S:\xLODGen

 

Becaurse of disc space I had to install FO4 to an other drive than Steam, which is at E:\Steam\SteamApps\...

I'm on Win7 64bit, language is german.

 

Are the worldspace records for Goodneighbour or Diamond City changed by plugins?

No, there should not be anything that does that. I've also tried generation without mods and unedited inis.

Edited April 5, 2018 by SpaceMad

[Vos80]

Correct, it will use the single texture for the ones that are not on the atlas, so it is not optimal for performance, but testing this hopefully helps us understanding this problem better.

I've got it working now.

 

First I looked in the NIFs for the alpha threshold. I couldn't tell what the value of the NiAlphaProperty was, so I decided to look in the material file. The values in those files differe from each other, but I have to say that I don't know much about alpha values in meshes. I mainly did some texture work for the mod I'm working on. 

 

And the alpha value could explain the murky tree leaves, but I don't see how it would be related to the low-res textures on buildings and highways.

 

I decided to compress DXT1 with 1 bit alpha through LODGen, and the textures were still murky.

 

Than I used the vanilla alpha. Like you said, the new trees are still being rendered with the loose texture files. I copy pasted the rest on the vanilla texture, and uploaded it in DXT1 with 1 bit alpha as well. 

 

This is the result:

 

 

And the textures on the highways are decent as well:

 

Overall, I'm content with the LOD for XB1.

 

So to clarify: I uploaded both texture atlasses as DXT1 with 1 bit alpha. One generated through LODGen (looked normal in Photoshop), and the other one edited by hand. All meshes are generated through LODgen, and the new trees are rendered as well. So the problem seems to lie with how the rendered atlas is applied. I hope this helps with problem solving, since I don't know the specifics of how it works. PLease ask if you need more information, and thanks for the assistance.

[sheson]

I've got it working now.

 

First I looked in the NIFs for the alpha threshold. I couldn't tell what the value of the NiAlphaProperty was, so I decided to look in the material file. The values in those files differe from each other, but I have to say that I don't know much about alpha values in meshes. I mainly did some texture work for the mod I'm working on. 

 

And the alpha value could explain the murky tree leaves, but I don't see how it would be related to the low-res textures on buildings and highways.

 

I decided to compress DXT1 with 1 bit alpha through LODGen, and the textures were still murky.

 

Than I used the vanilla alpha. Like you said, the new trees are still being rendered with the loose texture files. I copy pasted the rest on the vanilla texture, and uploaded it in DXT1 with 1 bit alpha as well. 

 

This is the result:

 

 

And the textures on the highways are decent as well:

 

Overall, I'm content with the LOD for XB1.

 

So to clarify: I uploaded both texture atlasses as DXT1 with 1 bit alpha. One generated through LODGen (looked normal in Photoshop), and the other one edited by hand. All meshes are generated through LODgen, and the new trees are rendered as well. So the problem seems to lie with how the rendered atlas is applied. I hope this helps with problem solving, since I don't know the specifics of how it works. PLease ask if you need more information, and thanks for the assistance.

Would you mind uploading the two atlasses, the one that works and the one that doesn't for comparison?

[antip]

Having the same problem with blurry textures unfortunately. It seems like the problem in the LODGen's atlas name. If i rename output textures and path in the mesh to vanilla it fixing the problem. Here is the screen. Generating only meshes without new atlas works fine, since the path to the textures don't change.

Edited April 6, 2018 by antip

[sheson]

Having the same problem with blurry textures unfortunately. It seems like the problem in the LODGen's atlas name. If i rename output textures and path in the mesh to vanilla it fixing the problem. Here is the screen. Generating only meshes without new atlas works fine, since the path to the textures don't change.

While it seems silly that the filename should matter how textures are treated, it would not surprise me one bit.

 

See if xLODGen Beta 12, which uses the vanilla name, works different (Vanilla name as long as the atlas does not have to be split because of size constraints).

Edited April 6, 2018 by sheson