sheson

You uploaded the LODGen_log.txt and not the xLODGen log. You clearly did something very odd by still having game mode FO4 and setting the Skyrim data folder. Read the first post and the readmes included in the download archive. https://dyndolod.info/Help/xLODGen

No.

Add RenderTexturesSingleThread=1 under TexGen in ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI and test if it runs through.

Still waiting for requested information. I would suggest to check the transparent areas of the full texture. It may be useful to fill the transparent areas with a darker color. Alternatively it might help to set ObjectLODForceAverageColor=1 in the ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini

Moved to the DynDOLOD 3 Alpha thread. Read the first post which debug log to also upload. https://dyndolod.info/Official-DynDOLOD-Support-Forum The log you uploaded only contains one session. It is unclear if when the unresolved errors happen. If updating does not work, then start from scratch as the message says. See https://dyndolod.info/FAQ "High memory usage / Out of memory"

If a 3D tree LOD model does not match the size of the full model tree, then there is a problem with the 3D tree LOD model. As explained before, while the game typically ignores translation, rotation, scale on the root node when placing references, LOD generation does not. Remove any translation, rotation and scale from the root of the 3D tree LOD model.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum how to provide logs and actual information when making posts. Read the answers for Billboard tree LOD shows in active exterior cells at https://dyndolod.info/FAQ

https://dyndolod.info/Help/DynDOLOD-Resources DynDOLOD requires the Core Files of DynDOLOD Resources.. They are not called TexGen Resources.

It is very unlikely that checking this options causes the OS to terminate the tool as described. Nothing about that option changed in the past several alpha versions.

Object LOD is made from references. The amount of cells does not really matter. Empty cells generate flat terrain or water LOD. Which only takes seconds to generate and does not really cost that much of performance to render. You should not wonder if 30x30 cells is different to 40x40 in case of LOD. That is the same in terms of LOD level 32 that covers 32x32 cells anyways.

The logs you uploaded seem to show what happens when you start the tool, click High on the advanced settings and then Click Cancel. Clean out the log folder. Enable the realtime log https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Select at least a worldspace, select at least one option to generate, like object, tree and dynamic LOD. Upload logs including the real time log and bugreport.txt if it exists. Also check the Windows Event log.

Moved to the DynDOLOD 3 Alph athread. Read the first post which log, debug and bugreport.txt if it exists to upload. https://dyndolod.info/Official-DynDOLOD-Support-Forum From https://dyndolod.info/Help/Texconv 80070070 There is not enough space left on the disk to which Texconv is trying to writing to.

23.2.2.230217 does not seem to be latest WHQL recommended driver? Did the problem happen without setting GLListDebug and GLDebug? Test with RenderSingle=1 added under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Windmill fans are dynamic LOD objects that replace the original references so that the same reference is used for LOD and also shows in active cells. LOD from the parent also shows in childworlds that use the parent world for LOD. For windmill fans that also means active childworld cells just the same as it does for the parent world. If the large reference copying for the large reference workarounds happens to also automatically creates copies for the windmill and other buildings that patch manually adds, then don't bother with the patch to avoid conflicts. In case the patch is still needed for something, do not edit the generated plugins. Instead edit the patch in the ..\Data\DynDOLOD folder by removing unwanted lines. Copy the patch file to a new mod so it overwrites the patch file in DynDOLOD Resources, then you never have to bother about it again. To find which line to remove look at the editor ID of a reference added by the patch, for example: whiterunexterior_tamrielpatch_00000D_DynDOLOD_PATCH_DynDOLOD_NOLOD Take note of the highlighted hex line counter: 00000D = line #13. The first non commented // line is #0. e.g. overwrite=skyrim.esm;0001a279,XCLW=-4700.000000 So the 13th line to remove from WhiterunExterior_Tamriel.patch would be: overwrite=skyrim.esm;000e8ecb,REFR=new,EDID=NOLOD,NAME=skyrim.esm;00022468,DATA\Position\X=34320.523437,DATA\Position\Y=-14425.012695,DATA\Position\Z=-4481.890137,DATA\Rotation\X=359.9769,DATA\Rotation\Y=359.4513,DATA\Rotation\Z=183.5520 You can use the base record (NAME=skyrim.esm;00022468) and position to doublecheck you got the right line.

Thanks. Generate with Alpha-126. That should fix that. If that works without the Whiterun Exterior patch, you can then try enabling the patch again. Make close observation of close by objects right beyond the wall, like farm, windmill buildings if the patch is necessary or not.

Do not install the Whiterun Exterior patch if it conflicts with other mods. For example, "natural" waterfalls disables vanilla waterfalls and adds new waterfall references. The exterior patch is for the vanilla game and vanilla waterfalls. Generate without the patch and check things look OK then. I would prefer screenshots instead video https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots https://dyndolod.info/Help/Mesh-Mask-Reference-Rules The order of rules matters. Rules at the top match before rules at bottom. Reference Form ID rules always take precedence over Mesh Mask rules which target base records.

Moved to the DynDOLOD 3 alpha thread. Read the first post which debug log and bugreport.txt if it exists to also upload when making posts. https://dyndolod.info/Official-DynDOLOD-Support-Forum https://dyndolod.info/Installation-Instructions Use the x64 versions of DynDOLOD/TexGen. The x86 versions may run into memory errors especially with large texture resolution settings and are included in case a x86 OS is used. They are functionally identical, the only difference is the supported CPU architecture. https://dyndolod.info/FAQ "High memory usage / Out of memory" Use the x64 versions of the tools.

You understand object LOD generation is combining a bunch of single meshes into larger meshes. Terrain LOD is building a mesh from a height map. Terrain textures are "splatted" according to alpha layer information. There is no rendering. TexGen can barely load simple static NIFs and render a diffuse/normal map side view of it in a very controlled setting and format. Loading entire "cells" to render something from it is not possible at this time.

https://dyndolod.info/Installation-Instructions Use the x64 versions of DynDOLOD/TexGen. The x86 versions may run into memory errors especially with large texture resolution settings and are included in case a x86 OS is used. They are functionally identical, the only difference is the supported CPU architecture. https://dyndolod.info/FAQ "High memory usage / Out of memory" Use the x64 versions of the tools.

The logs you uploaded earlier are from generations that had an error. Make sure to generate a LOD patch without any errors. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots Make sure non of the TexGen/DynDOLOD output is being overwritten by other mods. Doublecheck the LOD Level 4 BTO coverting those cells has tree LOD in them. https://dyndolod.info/FAQ "Something does not have LOD" In particular make sure those tree have 3D tree LOD models/billboards discovered. https://dyndolod.info/Help/Ultra-Tree-LOD#Generating hints to *Tree_Report.txt., but it should basically have the same info as *Object_Report.txt for tree base records.

Yes, copy the valid data from JK's - ELFX Patch.esp to replace the truncated data in your custom version of Icy Windhelm. This height data only affects Occlusion data generation.

When I check xx11706D in JK's - ELFX Patch.esp it does have the expected length of 1096 bytes. https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format/LAND Use xEdit "Simple records" in its options to show the hex values for the VHGT - Vertex Height Map. Right click them, Edit. Copy/paste to the patch plugin.

What version of the mod/plugin are you using? 2.2 with plugin CRC32 8A1EE12C does not have such a LAND record. Your plugin has CRC32:6D4591CB. Load load order into xEdit and lookup the form id. If you can not find the form id, It is possible the load order ID is reported wrong. Then use the cell finder (SHIFT+CTRL+F) to look up 31,8 in WindhelmWorld and check the listed plugins which is the last to contain the LAND record.

Once it is done saving plugins, the program is complete and just showing the the "check log" option to be closed via X top right. Let me know which plugin is 6D that contains the LAND record 6D0162D5 which has the wrong height data. It may be corrupt.

You could try just Tamrriel first and if that runs trough the whole thing.