sheson

Thanks. I could replicate and fix that error in beta 50.

That's is not a very specific description of anything really. No idea what paths for what you are talking about. If there is an error message, reproduce it here. If it happens while generating LOD, post the entire DynDOLOD log. Install DynDOLOD and requirement, generate the LOD mod with dynamic LOD enabled, install its output according to the instructions.

If you like, upload it anyways for me to test. It probably has data in it that I didn't anticipate.

Markarth is not a child world using a parent world for LOD. The Markarth worldspace is a cut down version with basicaly no object references outside the city. There won't be much LOD to occlude. You might just skip over it. Check the object LOD mesh for that quad loads in NifSkope without problem (it should be fine, I would expect a proper error message if it had issues) meshes\terrain\markarthworld\objects\markarthworld.4.-44.-3.bto Object LOD included with the mod was generated with a really old version of LODGen. As the instructions to generate occlusion suggest, generate object LOD before calculating occlusion.

No need. It might also potentially end up as master, so better don't enable it.

Is that the complete Skyrim.ini you found in MOs profile folder for your profile? While it seems to have the required archive lines, it otherwise seems incomplete and missing stuff. Compare to the Skyrim.ini found the Users\[user]\Document\My Games\Skyrim\ If that is incomplete or modified as well, back it up as a different filename. Then start the games launcher once so it creates a default Skyrim.ini. Copy that over into the folder for your MO profile. (back up that Skyrim.ini as well). Then start xEdit/xLODGen/TexGen/DynDOLOD from MO and check the BSAs listed in the archive lines are mentioned their start up logs.

Do what the message says: Check the top of the log that all required *.BSA files are loaded. Check that C:\Users\profile\Documents\My Games\Skyrim\Skyrim.ini (MO users check ..\ModOrganizer\profiles\[profile name]\Skyrim.ini) is the default version and contains the correct entries for [Archive] sResourceArchiveList and sResourceArchiveList2. See DynDOLOD-README.txt for more:

Use latest version 2.71 or newer.

Yes, it is just that cell, a wild edit, being at otherworldly y coordinate of 258. The reason why DynDOLOD complains about the world bounds. You could actually just remove the cell from the plugin. xLODGen beta 49 now ignores such cells, so it won't trip over it.

One test I like to do, compare the full model with its glowing windows at the same distance as the LOD by using tfc in console. LOD has only limited shader support, but often it is just the way the engine works. Check the mipmaps of the glow map texture_g.dds of the third texture slot. Test if removing the mipmaps yields better results. Consider manually creating the mipmaps or using another mipmap shrinking texture algorithm in the graphics program you use edit textures. If you check the mipmaps of hhwin02noalpha_g.dds you will see that they basically just become a white pixel in the end. The usual algorithm would make it dark grey/black. You can also try increase to the Emissive Multipe value in the Shader of the glow LOD mesh a bit. ENB affects lighting, test without it for comparison. Good luck with the mod.

Replace executable with this xLOdGenx64.exe and see if it tells us more about the error. It hopefully mentions the cell. Look up the cell in xEdit to find the plugin(s) adding/overwriting it.

It seems you are following/using an outdated guide or tool that wants you to download older versions of DynDOLOD. Older version of DynDOLOD are outdated and gone as newer version fix bugs and add compatibility with mods. Nobody should use older versions on purpose. I can not provide support for third party guides or tools. Ask the guide author/forum etc. for support. Download the current version of DynDOLOD and its requirements directly. Read the included manual for up-to-date instructions. Ignore any conflicting and especially outdated instructions from third party guides.

xLODGen beta 47 fixes an issue with FO4 vertex alpha added TVDT Occlusion data generation for Skryim/Enderal/Skyrim VR/Skyrim Special Edition xLODGen beta 48 fixes looking for some wrong object LOD texture filenames in FO4 xLODGen beta 49 ignore wild edit cells that are out of range for occlusion xLODGen beta 50 fix an error reading object LOD meshes for occlusion See the included Skyrim-Occlusion-Readme.txt for a brief explanation of the Skyrim TVDT Occlusion data generation. Read the hints that are shown when the mouse pointer rests on a setting. Ask specific questions or give feedback in the dedicated Skyrim TVDT - Occlusion Data thread.

xLODGen beta (47 or newer) and DynDOLOD (2.70 or newer) can be used to update or generate TVDT Occlusion culling data on cell records, which is famously wrong for some cells in Tamriel causing rectangular holes in the distant LOD. Please read the included documentation Skyrim-Occlusion-Readme.txt in the xLODGen archive and the TVDT - Occlusion Data section in Docs/DynDOLOD_Manual.html to learn about TVDT data, how to generate it and the settings. Mod users / complete load orders For Skyrim, Skyrim VR and Skyim Special Edition I generally suggest to use DynDOLOD 3/xLODGen to create an Occlusion.esp for the entire load order. Generating the Occlusion.esp is fairly quick with quality 2 and it means not having additional plugins as master in DynDOLOD. The Occlusion.esp is automatically ESL flagged for Skyrim Special Edition. Since DynDOLOD is just the advanced version of xLODGen for tree and object LOD generation, the code to generate the occlusion data and the results are the same. Using DynDOLOD has the advantage that the occlusion is generated automatically with pre-defined settings in the DynDOLOD INI as part of the LOD generation process. Using xLODGen has the advantage of being able to update a separate plugin which only contains the occlusion data and nothing else more quickly and even for a specific worldspace only. For Enderal it seems more convenient to have DynDOLOD generate the data into the DynDOLOD plugin, so in DynDOLOD it is enabled by default for Enderal only. There are also additional optimizations in DynDOLOD for Enderal that help improve performance in certain locations. In xLODGen the Occlusion generation is an additional option below the Terrain LOD options. See the included documentation for information about the settings. Once generation is complete, Occlusion.esp is saved to the data folder (or MO mod folder / MO Overwrite folder accordingly). To make sure its updated TVDT data is used, ensure the Occlusion.esp is loaded last so it overwrites any other plugin. Generate the Occlusion.esp last. So the order would be: Finalize load order use xLODGen to generate terrain LOD meshes [and textures] use TexGen/DynDOLOD to generate drastically improved object and tree LOD (uses terrain LOD meshes for object LOD optimization) use xLODGen to create Occlusion.esp (uses object LOD meshes to determine max height samples) If the load order changes afterwards and a plugin makes changes to WRLD/CELL records, the entire worldspace should be updated in the Occlusion.esp (unless the new plugin loads after Occlusion.esp of course). Worldspaces in Occlusion.esp can be updated by simply starting xLODGen with the current Occlusion.esp being last in the load order. Select the desired worldspaces only and generate Occlusion for it. The selected worldspace is removed from Occlusion.esp and then generated completely anew for the new load order. Other worldspaces in the Occlsuion.esp will not be changed. Mod authors It is possible to update the TVDT data on CELLs in a single plugin by starting the tool in edit mode. Generate/Update object LOD first so the object LOD meshes match the current state of the worldspace. As suggested in the included documentation, generate max height data for all cells with CK beforehand. You are welcome to test the included MHDT generation as well. Consider defining/updating the Border Region for the worldspace so the +Border filter option can be used. Either start xLODGen.exe in edit mode with the -edit command line or rename xLODGen.exe to [Gamemode]Edit.exe e.g. TES5Edit.exe Select loading of plugins as usual. Right click desired plugin in the left tree view, click Other, Generate LOD. Check Occlusion and verify the text next to it mentions the desired plugin to be updated. Adjust other settings as desired and explained in the included documentation. For large / multi people projects it is probably better to generate an Occlusion.esp the usual way and merge the TVDT data. Stick to the usual workflow. As always, mod authors are welcome to direct message me here or on discord for help with their projects. Read the provided information and in case of questions about occlusion generation, post them in this thread regardless of using xLODGen or DynDOLOD.

Thanks. I was able to replicate. Will be fixed next version. Edit: DynDOLOD 2.70 with the fix is now released.

So far the flag is always set for any base record which has static or dynamic LOD without a problem. Though it seems it might be fine to not set the flag for base records not added by ESMs, thus this is what the next DynDOLOD version will do. In case that causes new issues, it won't be long for them to show and be reported and we will learn more about it and refine when to use it. Edit: DynDOLOD 2.70 is now released.

Yes, the manual is thin on the details for that. Make sure to read the Glow LOD Windows section in the manual: Checking the [x] Windows option adds glowing LOD windows to all vanilla LOD buildings. Glow LOD Windows are independent meshes that are added in addition to the LOD of the object they belong to. If the [_] High option is not checked the glowing windows are added as static object LOD. Check the [x] High option to add glowing windows as dynamic object LOD if applicable. As explained above, dynamic object LOD windows react to external lighting. However, windows on vanilla forts for example are not using external emittance and consequently will always be generated as static object LOD. Most windows are automatically added to the FarGrid, some are added as neverfades that always show regardless of distance. This is determined by the *glow_lod_X.nif file name. If X equals _0 it is assigned to NearGrid (LOD4), _1 to FarGrid (LOD8) and _2 (LOD16) is a neverfade. The glow LOD windows are done as a separate meshes. If required (and if High Windows has been checked) they can be added as dynamic LOD in order for them to react to the external emittance (window lighting changes based on weather/light conditions) settings defined on the reference. Otherwise they will be simply merged into the static object LOD BTO. For example, if the LOD model has the file name house01_lod*, its glow LOD windows should have the file name house01glow_lod_*.nif. If checking [x] Windows, the glow LOD mesh is then automatically found whenever a reference uses house01_lod_1.nif. There are no additional settings required. Check the existing glow LOD meshes. They are also setting Decal, Dynamic_Decal on Shader Flag 1 and No_Fade on Shader Flag 2 as that will be help with the long distance visibility and z-fighting. The windows themselves typically float a bit in front of the LOD mesh for the structures. Now when you include the house01_lod* and its house01glow_lod* LOD meshes with your mod and then later users use DynDOLOD to generate LOD with the Windows and optional High settings checked, it should just work.

The log seems truncated. Upload the ESLs you created so I can try to recreate the issue.

I see. Interesting. Papyrus Util will be fine, I was just wondering if there might be any other plugins still active. Just unset the flag for now. Next DynDOLOD version will not set it.

FAQ: Game: Out of place objects / floating objects / flickering full models A: Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true with mods modifying the walled cities. Users are asked and welcome to provide feedback to https://forum.step-project.com/forum/101-shesons-dyndolod-support in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with console / form id) about issues if possible. The mod adds new references in the Tamriel parent world but also their counterparts to the WhiterunWorld child world, so they can be seen past the walls. DynDOLOD scans the child worlds for new references that can have LOD and automatically add facsimiles in the parent world. It filters out duplicates by their position/rotation, however sometimes the differences are too high and it fails. In cases like this, add plugin.esp=worldspace name to ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE]_mod_world_ignore.txt so the references in the child world are not picked up at all. So in this case it would be: Whiterun Gate Restoration.esp=WhiterunWorld Then generate LOD. If you are creating your own mod, ensure the positions/rotation of the same objects match closer, so the filtering works. Or if that is not possible, add the plugin name to the file to it filter out. In case you make the mod that needs custom rules public, you can include a rules file in the game data/DynDOLOD/ folder next to usual data/meshes or data/textures (it can also be packed into a BSA) DynDOLOD_TES5_whiterungaterestorationesp.ini [skyrim Settings]IgnoreWorlds=WhiterunWorld See DynDOLOD_Mod_Authors.html How to add rules for your own mod for more.

There are typically no setting that prevent loading of anything. Those are usually mod conflicts. In addition to cell water, there are also smaller water meshes which are placed as object references. Some of those have dynamic LOD by DynDOLOD.

LOD water is part of terrain LOD. The type of the LOD water is defined on the worldspace record. The water type is applied to the LOD water meshes while in the game, no need to generate LOD again if it changes.

FAQ: Game: ILS or CTD A: More LOD uses more memory and this can cause infinite loading screen (ILS) or crash to desktop (CTD) if the game is not setup correctly. This should generally not be a problem with Skyrim Special Edition or Skyrim VR, but for Skyrim double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Or use the alternative OSAllocator from crash fixes with pre-loader. Remove satefy-load if it is used. Setup ENBoost correctly. Set ExpandSystemMemoryX64=false in enblocal.ini. A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. A: Large load orders with many plugins might surpass the reference handle cap. SSE Engine fixes prints a warning. See https://www.reddit.com/r/skyrimmods/comments/ag4wm7/psa_the_reference_handle_cap_or_diagnosing_one_of/ Setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution. If you didn't see a NIF name in Crash Fixes crash log, then it's probably not a corrupt mesh. Even so, still enable debug in the json/txt and then check the papyrus log for which NIF dynamic LOD enabled last. If that doesn't reveal anything, see if hiding the meshes folder from the DynDOLOD output changes anything. I suspect not, but you never know. Then hide the SKSE folder, ignore the expected error messages about data not being found in the json/txt files, just test if it CTDs or not. If it still CTDs, test if it still crashes with only the DynDOLOD.esm Report back on these tests.

Can you explain what you mean exactly by "collision disabled"? You mean in the NIF? Next version of DynDOLOD will not set the flag then. It's just a precaution, that is probably fine to be skipped in this context. Still would be good to understand this issue better. You mentioned earlier you also disabled everything else, did that include all SKSE plugins or other non SKSE DLLs?

DynDOLOD uses whatever models and textures that are winning the overwrite order defined by the mod manager you are using.