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

[sheson]

Hi, new Xlodgen-user here! Tried to generate my first terrainlod today (I've been running Dyndolod a lot with great results) but it seems I made a small mistake by accidently putting a blank space after the "-o: C:\Users\..." which put all of my generated output files in the games datafolder ( \steamapps\common\Skyrim Special Edition\Data\Meshes\terrain ...). At least thats what the logfile says... How can I solve this? As soon as I realised my mistake I deleted the blank space (-o:"C:\Users\...) and now the generated output files are where I want them, so maybe I can just install these and go on with generating Texgen and Dyndolod? Or do I have to find and delete all the old files in the datafolder first? Im using Vortex btw.

This is a basic modding question unrelated to xLODGen about loose files in the data folder and loose files installed by the mod manager.

Typically there should be no loose files in the data folder and everything should be installed only with a proper mod manager.

[TheDude]

Sorry, but what do you mean by "unrelated to Xlodgen"? My question was regarding the Xlodgen-output files since I had entered an incorrect output path in my mod manager and was afraid everything had been put in the games datafolder (which seems to be a big no-no according to the instructions on page 1). 

"Use -o:"c:\OutputPath\" commandline parameter to change where files are generated to, default is the game folder. Use this if a mod manager with a virtual file system (like MO) is used. Do not generate into any game or any mod manager folders that are part (direct or indirect) of the virtual file system."

 

But ok, nevermind, I'll just generate new files in a proper output path this time.

Edited July 21, 2020 by TheDude

[sheson]

Sorry, but what do you mean by "unrelated to Xlodgen"? My question was regarding the Xlodgen-output files since I had entered an incorrect output path in my mod manager and was afraid everything had been put in the games datafolder (which seems to be a big no-no according to the instructions on page 1). 

"Use -o:"c:\OutputPath\" commandline parameter to change where files are generated to, default is the game folder. Use this if a mod manager with a virtual file system (like MO) is used. Do not generate into any game or any mod manager folders that are part (direct or indirect) of the virtual file system."

 

But ok, nevermind, I'll just generate new files in a proper output path this time.

It is unrelated because writing new or existing files into the games data folder that is under control of a mod manager is always a very bad idea, regardless of the tool or the particular files.

 

The negative effects or issues that arise from writing or having loose and uncontrolled files in the data folder applies to all files, regardless how they got there.

 

Also, the solution is always the same, remove the loose files and install with the mod manager.

Edited July 22, 2020 by sheson

[TheDude]

Yeah, I did that and everything, including new terrainlods, seems to work fine now, thanks. I guess I just gotta be careful about putting blank spaces in output paths from now...

 

Edit: it was actually really easy to find and delete the old files, since Vortex had named them ".backup" in favour of using the new files. So problem solved!

Edited July 22, 2020 by TheDude

[HunterZ]

I recently started playing Skyrim SE and decided to try playing with xLODGen (*no* DynDOLOD yet). Despite following various guides closely, I've had some indeterminate results such as Skyrim crashing on save file load and xLODGen crashing during generate. I was ultimately able to get it to work with various settings, however, and collect results.

 

One major thing I noticed is that xLODGen generated LOD data seems to no longer have any of the white (snow?) that is present in the vanilla LOD. Is this expected? The "improved" snow shader is OFF, and mod list is at the bottom of this post.

 

Vanilla LOD - note white snow highlights:

 

LOTD LOD - very dark textures:

 

STEP LOD - not as dark, likely due to 1.25 gamma recommendation:

 

Mod list:

[spoiler=mod list](Part 1) Engine Fixes-17230-5-4-0-1597134892

All in one-32444-2-1582543914
Better Dialogue Controls v1_2-1429-1-2
Better MessageBox Controls v1_2-1428-1-2
Cathedral - Weathers-24791-2-22-1583904997
Cathedral Weathers MCM-24940-1-3-1578270480
Enhanced Ore Veins - 2K - 8.0-1306-8-0-1595238568
Flora Respawn Fix SSE - 2.1.3.zip-13186-2-1-3
Immersive HUD - iHUD-12440-0-2b
JContainers SE-16495-4-1-12-1574419908
kart_CSSET-38775-1-2-1596977529
KeyboardShortcutsFix_SKSE64-3620-1-0-0-2
More Informative Console for SKSE 2.17-19250-0-34-1574384572
More Visible Arrows and Bolts SSE-5626-2-0-1550387867
output
Relighting Skyrim SSE v1.1.0-8586-1-1-0-1573083114
Skyrim_Particle_Patch_for_ENB-SSE
SkyUI_5_2_SE-12604-5-2SE
SMIM SE 2-08-659-2-08
SSE Display Tweaks-34705-0-4-5-1597351089
Unofficial Skyrim Special Edition Patch-266-4-2-3-1587854191
Vidani's Bag of Holding-16977-2-1
VioLens - A Killmove Mod SE 2.22a-668-2-22a-1560801018

 

 

Plugin list:

[spoiler=Plugins]Skyrim.esm
Update.esm
Dawnguard.esm
HearthFires.esm
Dragonborn.esm
Unofficial Skyrim Special Edition Patch.esp
kart_CSSET.esp
kart_CSSET0.esp
kart_CSSET00.esp
kart_CSSET000.esp
kart_CSSET0000.esp
SSE-Terrain-Tamriel.esm
SkyUI_SE.esp
FloraRespawnFix.esp
SMIM-SE-Merged-All.esp
Cathedral Weathers.esp
CathedralWeatherMCM.esp
CC'sEnhancedOreVeinsSSE-HearthfirePatch.esp
RelightingSkyrim_SSE.esp
Particle Patch for ENB SSE.esp
VioLens SE.esp
Vidani's Bag of Holding.esp
iHUD.esp
Bashed Patch, 0.esp

 

[sheson]

I recently started playing Skyrim SE and decided to try playing with xLODGen (*no* DynDOLOD yet). Despite following various guides closely, I've had some indeterminate results such as Skyrim crashing on save file load and xLODGen crashing during generate. I was ultimately able to get it to work with various settings, however, and collect results.

 

One major thing I noticed is that xLODGen generated LOD data seems to no longer have any of the white (snow?) that is present in the vanilla LOD. Is this expected? The "improved" snow shader is OFF, and mod list is at the bottom of this post.

First post:

 

It seems that only Skyrim CK and Skyrim SE CK are manipulating the intensity of the textures to adjust for the noise.dds and the god awful "improved" snow shader of Skyrim SE (just turn that thing off, really). If textures seem too dark in the game, brighten the noise.dds instead or vice versa. That way you can get perfectly matching LOD textures that look just like the textures in the loaded cells. For Skyrim a good average color of the noise texture seems to be around #C0. See below for a couple noise texture downloads.

 

With brightness, contrast and gamma left alone - as it should be and just like with object LOD - the generated terrain LOD textures look exactly as the full landscape textures being used to create them. This will ensure perfect terrain blending and matching with object LOD textures. If you were to check any of the snow textures in the textures/landscape/ folder you might notice that snow textures are not bright white. We expect LOD to match and not be comically wrong like vanilla LOD as can be seen in this post.

Edited August 23, 2020 by sheson

[z929669]

Apparently, that (crappy) vanilla snow LOD is only white because of the vanilla version of /textures/terrain/noise.dds in combination with the vanilla terrain LOD... With Cathedral Landscapes (CL) and Majestic Mountains (MM) installed (as in STEP), CL provides the noise map. The gamma correction noted in the STEP guide results in the terrain snow LOD (as well as other terrain) matching the rest of the mountains/rocks objects as well as the full terrain (as in your third image, which IMHO looks correct and consistent with the rest of the landscape). Sheson has told us again and again that the brightness/gamma corrections technically should not be used, because xLODGen is using the full (base) terrain textures to produce the terrain LOD. This should ensure that all terrain matches whether near or far IF the noise map is compatible (note that the 'flat' noise map should be totally compatible with any terrain LOD; although, you will see the terrain tiling).

 

No noise texture edit that Tech and I have played with result in a 'good' result with CL and MM ... this includes the 'flat' noise map that sheson provides in the OP. The terrain textures are always too dark, and ONLY a brightness correction (or gamma) achieves the desired result with the CL noise map and landscapes ... Tech and I have tested and tested, regenerating terrain LOD over and over again to no avail.

 

Ultimately, the issue lies with the CL mod in that they designed a dark-ish noise map and used xLODGen for the terrain LOD to work with that (again, brightening that CL noise map using various methods does not look as good as the brightness correction ... the noise map would need to be redesigned to maintain the white-gray-black steepness and granularity, which we did NOT do in our testing). And yes --contrary to sheson's advice-- they did use a brightness correction in their LOD gen that ships with their mod, so we are technically deviating from best practice by using a brightness correction in our LOD gen methods simply because we are trying to get everything to look consistent and must replicate CL methodology (note that we are using gamma rather than brightness, because it preserves more of the LOD color saturation).

[HunterZ]

I'm assuming CL refers to Cathedral Landscapes. Note that per the mod list in my previous post I am not using that mod, because I'm trying to start more conservative than STEP.

 

What I think I'm getting out of your replies (thanks BTW) is that the bright white stuff in the vanilla LODs is considered to be an undesirable artifact (or possibly artistic license) on Bethesda's part, and does not reflect the actual landscape?

 

Since I'm not using CL, should I be messing with noise textures, or is the 1.25 gamma just as good, or something else? I understand this may be a controversial topic, so all opinions are welcome.

 

 

Another issue I noticed is that there seems to be some weird z-fighting at the edge of grass range (probably where LOD4 kicks in?). I made xLODGen and vanilla LOD flyover videos to demonstrate. Note that I have installed Better Dynamic Snow SE and regenerated with STEP settings since my previous post.

 

Vanilla:

 

xLODGen:

[z929669]

You will get z fighting in certain areas no matter what you do, but there are ways to minimize.

 

If you are not using CL, then you shouldn't need any gamma correction ... that's for the STEP build using CL and MM. However, from the images in your previous post, the gamma correction yields the best result. Terrain LOD snow matches objects and the landscape in your last image.

 

The vanilla snow in your first image may match pretty well in vanilla, but I assume that your replaces or lighting weathers are making mountains/rocks mismatch terrain, so it looks like fuzzy day-glow snow to me. Terrain LOD in the second image looks like volcanic ash, so you either need a lighter noise map or the xLODGen brightness/gamma correction, because -- for whatever reason, your LOD terrain doesn't match up to the landscape, IMO.

 

... anyway, please follow sheson's advice. I just chimed in here, since you are using xLODGen settings recommended by the STEP guide (which expects that you are using CL/MM).

[HunterZ]

I mention the z-fighting because it's not there with the vanilla LOD. Note that this is not water z-fighting, but rather it seems to be LOD failing to blend with full-quality terrain at cell borders or something.

 

The screenshots are only useful as comparisons with each other, as they are heavily orange-tinted as a result of being at dawn. Both of my flyover videos are recorded at just after midday game time.

[sheson]

Let me repeat this: CL uses specific LOD textures for terrain LOD texture generation only. They do not match the full textures. In this case using brightness/contrast/gamma to make a final adjustment is perfectly fine. It is equivalent to using an image program to create or adjust those special textures to match the full textures better.

 

If the same landscape textures are used for LOD generation and in-game, then using brightness/contrast/gamma means terrain LOD textures will not match full terrain and object LOD. Using the noise texture to adjust brightness the opposite way again to make things match again, means doing two unnecessary things (with different methods) to the terrain LOD textures trying to make them match again.

 

Can't say I have seen such loading flicker as seen in the second video before. Did you generate with mipmaps for diffuse/normal maps? Otherwise I would suspect resource issue, e.g. very large meshes or texture resolutions. My first troubleshooting step would be to only use the new terrain LOD meshes and then only the new terrain LOD textures only, to see which of the two is the reason.

Edited August 24, 2020 by sheson

[HunterZ]

I used the STEP settings, which have mipmaps disabled: https://wiki.step-project.com/STEP:0.3.0b#Generation

 

Someone said in another thread that you told them that mipmaps aren't used, so apparently we're all confused about what to do now: https://forum.step-project.com/topic/15184-xlodgen-terrain-settings-compare/page-2?do=findComment&comment=242498

 

To my knowledge, I'm not using any textures that are larger than what come with Skyrim SE - just higher quality versions of some of them.

 

It sounds like I should try the following to diagnose the flickering, until/unless one of them is spotted as the culprit:

1. Generate with mipmaps enabled?
2. Generate only meshes and see what happens.
3. Generate only diffuse/normal maps and see what happens?

 

[HunterZ]

Update - it's definitely the meshes that are involved in the cell edge flickering:

• Everything with mipmaps enabled: Flicker
• Just meshes: Flicker
• Just textures: No flickering

 

Trying some different mesh options:

• Reducing LOD4 mesh quality 1 and 2: Flicker
• Turn off protect borders: Flicker
• Turned off baked normals (don't think this applies but I'm grasping at straws now): Flicker
• Generated without SSE-Terrain-Tamriel.esm and with Bashed patch active: Flicker

 

Went back to vanilla LOD data, and verified no flicker, so I'm at a loss as to what else I can do. Maybe disable various mods before generating meshes?

[sheson]

Update - it's definitely the meshes that are involved in the cell edge flickering:

• Everything with mipmaps enabled: Flicker
• Just meshes: Flicker
• Just textures: No flickering

 

Trying some different mesh options:

• Reducing LOD4 mesh quality 1 and 2: Flicker
• Turn off protect borders: Flicker
• Turned off baked normals (don't think this applies but I'm grasping at straws now): Flicker
• Generated without SSE-Terrain-Tamriel.esm and with Bashed patch active: Flicker

 

Went back to vanilla LOD data, and verified no flicker, so I'm at a loss as to what else I can do. Maybe disable various mods before generating meshes?

Keep only the terrain LOD Meshes for level 4 (tamriel.4.*.*.btr), so we can rule out further away terrain LOD meshes affecting this. Remove tamriel.[8|16|32].*.*.btr, so it will fall back to use the vanilla meshes for those.

 

If still happens then, let me know the generation settings used for LOD level 4.

Edited August 25, 2020 by sheson

[HunterZ]

Confirmed - using just LOD4 meshes still results in flickering.

 

Here are the settings used. Log reports app version SSELODGen 4.1.3b EXTREMELY EXPERIMENTAL Terrain LOD BETA x64 (B97D7181):

Edited August 25, 2020 by HunterZ