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

[z929669]

2 hours ago, Pawelekdabek said:

Maybe this is dumb question but is it possible to somehow generate terrain lod that will use full model of water mesh? Would it be too performance heavy? I want to get rid off this ugly water seam in the distance.

Somewhere previously, sheson mentioned that water LOD is not created by DynDOLOD. I think he mentioned that terrain gen only needs to know what is and is not water. The seams are a game-engine limitation that can be dealt with by other trickery, like ENB. I see them as well with/wo ENB, but only when flying around at 1000 meters.

[Pawelekdabek]

Understood, thanks. 

I have another question. I followed S.T.E.P for SSE guide for xlodgen terrain generation and lost few fps. Is it normal?

Edited April 25, 2021 by Pawelekdabek

[z929669]

On 4/24/2021 at 5:19 PM, Pawelekdabek said:

Maybe this is dumb question but is it possible to somehow generate terrain lod that will use full model of water mesh? Would it be too performance heavy? I want to get rid off this ugly water seam in the distance.

I never quantified the 'cost' of terrain LOD, but we should probably stop recommending 512 resolution at LOD4 and LOD8 and use 256 instead. sheson mentioned that there is no perceptible difference unless you have a 4k-8k monitor. Doing this may help you get back some frames. LOD32 still benefits slightly from 512, depending on a number of factors.

You can also raise the quality of LOD4 and LOD8. I believe the default is 5. And 10 for LOD16, IIRC.

[Pawelekdabek]

1 hour ago, z929669 said:

You can also raise the quality of LOD4 and LOD8. I believe the default is 5. And 10 for LOD16, IIRC.

It is 0,2,4,4 for LOD4->8->16->32. Maybe it is too much? I tested it on almost clean vanilla setup and performance hit was something around 12 FPS. But again, it was from 124 to 112 FPS. I think it would be tad bit lower with more mods installed.

[sheson]

On 4/25/2021 at 12:19 AM, Pawelekdabek said:

Maybe this is dumb question but is it possible to somehow generate terrain lod that will use full model of water mesh? Would it be too performance heavy? I want to get rid off this ugly water seam in the distance.

That is not how water LOD works in the terrain LOD meshes works. There is only a general Water Shader hat can be defined. The world space record then defines which water record is actually used for all water LOD of the worldspace.

8 hours ago, Pawelekdabek said:

Understood, thanks. 

I have another question. I followed S.T.E.P for SSE guide for xlodgen terrain generation and lost few fps. Is it normal?

Higher settings/resolutions require more resources, obviously.

[sheson]

2 hours ago, z929669 said:

I never quantified the 'cost' of terrain LOD, but we should probably stop recommending 512 resolution at LOD4 and LOD8 and use 256 instead. sheson mentioned that there is no perceptible difference unless you have a 4k-8k monitor. Doing this may help you get back some frames. LOD32 still benefits slightly from 512, depending on a number of factors.

You can also raise the quality of LOD4 and LOD8. I believe the default is 5. And 10 for LOD16, IIRC.

The settings, instructions and recommendations for TexGen, which generates object LOD textures and billboards, obviously have no correlation to terrain LOD whatsoever. What resolutions are useful for terrain LOD in what scenarios are completely different. 

[Pawelekdabek]

1 hour ago, sheson said:

The world space record then defines which water record is actually used for all water LOD of the worldspace.

So not possible to eliminate this water lod seam?

[sheson]

1 hour ago, Pawelekdabek said:

So not possible to eliminate this water lod seam?

Make all water and the LOD water use the same/similar water or  change how the engine/water works.

[Zanderat]

On 4/23/2021 at 9:39 AM, Katarsi said:

I would like to add more to A Quality World Map compatibility with generated xLODGen Terrain. Not applicable to Paper Map (I wouldn't know because I don't use it).

If this compatibility guide isn't followed, the map will look utterly distorted. I learned this the hard way.

First off, QWM textures are packed into a BSA, so loose files will always overwrite it. Generated Terrain contains loose files that will overwrite QWM, no matter where it is in the load order. Also, generated Terrain contains meshes for the map, which will mess it up because QWM is tailored for default map meshes.

Instructions:

• After generating Terrain and activating it, open up its folder (for me it's SSELODGenOutput).
• Go to textures/terrain/dlc2solstheimworld and remove every file that starts with dlc2solstheimworld.32. They are normally the last files in that folder if they are sorted by name.
• Go to textures/terrain/tamriel and remove every file that starts with tamriel.32. The same application as above.

I could mention that xLODGen is efficient to the point that it creates even normal maps of textures (_n.dds), while QWM doesn't have them. It's no biggie though, the map of this mod still looks awesome. I'm not sure about keeping these normal maps in generated Terrain, given they can differ in size from QWM textures, depending on the chosen quality when generating Terrain. The size of QWM textures is 1024x1024. If someone has an input on this, you're welcome to pitch in.

• Go to meshes/terrain/DLC2SolstheimWorld and remove every file that starts with DLC2SolstheimWorld.32. No exceptions.
• Go to meshes/terrain/Tamriel and remove every file that starts with Tamriel.32. No exceptions, as above.

These two steps are very important, because THIS is what primarily distorts the map! xLODGen generates meshes (.btr) that don't fit with QWM map textures.

Also, this whole removal shebang can be done even after all the LOD was generated (xLODGen, DynDOLOD, Occlusion), so don't worry about messing something up.

That's it, enjoy your beautiful terrain and A Quality World Map combo.

What I do is much simpler:  unpack the BSA that come with QWM as loose files and let them overwrite whatever is generated by xLODGEN using either Vortex or MO2.

[z929669]

7 hours ago, sheson said:

The settings, instructions and recommendations for TexGen, which generates object LOD textures and billboards, obviously have no correlation to terrain LOD whatsoever. What resolutions are useful for terrain LOD in what scenarios are completely different. 

I understand the distinctions. My point is that the default OOtB settings for xLODGen, TexGen, and DynDOLOD are probably close to optimal for most systems that are not higher-end with 4k-8k resolutions. Terrain LOD4/8 textures at 256k are not obviously distinguishable on my 2k monitor from current recommendations in the Step guides (512k). Same goes for quality of 0/2/4/4 (Step) vs 5/5/10/5 (closer to default when running xLODGen for the first time, IIRC).

I can see slight improvements with the higher settings, but only on direct compare of screens, and the improvements are marginal at best ... not significant IMO. Given the trade-off, the FPS/VRAM hit is probably not worth the very marginal quality gain unless the resource ceiling leaves a lot of room to spare.

[sheson]

20 minutes ago, z929669 said:

I understand the distinctions. My point is that the default OOtB settings for xLODGen, TexGen, and DynDOLOD are probably close to optimal for most systems that are not higher-end with 4k-8k resolutions. Terrain LOD4/8 textures at 256k are not obviously distinguishable on my 2k monitor from current recommendations in the Step guides (512k). Same goes for quality of 0/2/4/4 (Step) vs 5/5/10/5 (closer to default when running xLODGen for the first time, IIRC).

I can see slight improvements with the higher settings, but only on direct compare of screens, and the improvements are marginal at best ... not significant IMO. Given the trade-off, the FPS/VRAM hit is probably not worth the very marginal quality gain unless the resource ceiling leaves a lot of room to spare.

xEdit/xLODGen is a CK replacement and its default settings are supposed to match the vanilla LOD files.

TexGen/DynDOLOD is the advanced version for drastically improved tree and object LOD for Skyrim. Its defaults are based on actual testing.

The point is, whatever I recommended and explain about TexGen, object LOD textures and billboards has no connection to terrain LOD. It requires its own and different testing.

[Pawelekdabek]

13 hours ago, sheson said:

Make all water and the LOD water use the same/similar water(...)

I guess this isn't as easy as it sounds? If I'm wrong, could you tell me how to do it?

Edited April 26, 2021 by Pawelekdabek

[sheson]

9 hours ago, Pawelekdabek said:

I guess this isn't as easy as it sounds? If I'm wrong, could you tell me how to do it?

By default CELL water use the water record defined on the worldspace record. Unless a CELL record defines its own. Those things can be edited with CK/xEdit.

[z929669]

@sheson

I'm getting a new reproducible fault for xLODGen64. It seems to happen towards the end of gen for all worlds during DLC2SolstheimWorld.

Log Name:      Application
Source:        Application Error
Date:          4/30/2021 10:29:29 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Description:
Faulting application name: xLODGenx64.exe, version: 4.1.3.1, time stamp: 0x60705f99
Faulting module name: KERNELBASE.dll, version: 10.0.19041.906, time stamp: 0x2f2f77bf
Exception code: 0x0eedfade
Fault offset: 0x0000000000034b59
Faulting process id: 0x855c
Faulting application start time: 0x01d73dd390256030
Faulting application path: C:\Modding\Tools\xLODGen\xLODGenx64.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 09a8a8fe-346f-444a-8157-e9b313c7ab42
Faulting package full name:
Faulting package-relative application ID:

Also, does it make sense to replace all instances of LODGenx64.exe with the version you pointed me to (i.e., I replaced this under DynDOLOD 3 alpha but not under xEdit or xLODGen app dirs.)?

EDIT: I got around the issue by copying all output from failed run to MO followed by gen of just DLC2SolstheimWorld and DLC2ApocryphaWorld. I then copied that to the mod with overwrite.

EDIT2: I just noticed that I generated terrain without first activating the SSE-Terrain-Tamriel.esm ... not sure if that could be a potential cause

EDIT3: I should also note that I am running the latest 77 beta

UPDATE: It ran without issue after including SSE-Terrain-Tamriel.esm

[sheson]

1 hour ago, z929669 said:

@sheson

I'm getting a new reproducible fault for xLODGen64. It seems to happen towards the end of gen for all worlds during DLC2SolstheimWorld.

Log Name:      Application
Source:        Application Error
Date:          4/30/2021 10:29:29 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Description:
Faulting application name: xLODGenx64.exe, version: 4.1.3.1, time stamp: 0x60705f99
Faulting module name: KERNELBASE.dll, version: 10.0.19041.906, time stamp: 0x2f2f77bf
Exception code: 0x0eedfade
Fault offset: 0x0000000000034b59
Faulting process id: 0x855c
Faulting application start time: 0x01d73dd390256030
Faulting application path: C:\Modding\Tools\xLODGen\xLODGenx64.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 09a8a8fe-346f-444a-8157-e9b313c7ab42
Faulting package full name:
Faulting package-relative application ID:

Also, does it make sense to replace all instances of LODGenx64.exe with the version you pointed me to (i.e., I replaced this under DynDOLOD 3 alpha but not under xEdit or xLODGen app dirs.)?

EDIT: I got around the issue by copying all output from failed run to MO followed by gen of just DLC2SolstheimWorld and DLC2ApocryphaWorld. I then copied that to the mod with overwrite.

EDIT2: I just noticed that I generated terrain without first activating the SSE-Terrain-Tamriel.esm ... not sure if that could be a potential cause

EDIT3: I should also note that I am running the latest 77 beta

UPDATE: It ran without issue after including SSE-Terrain-Tamriel.esm

Always post the log please. 

The SSE-Tamriel--tamriel.esm should not affect this,  unless there is a plugin in the load order also adds the same missing cells maybe.

Try the version from 

it should create a bugreport.txt.