sheson

This looks like FAQ: Skyrim: Out of place objects / flickering full models

Looking great.

It probably means something went wrong with the generation. Did you follow the the special 2-pass LOD generation for Open Cities correctly?

On first glance the "DynDOLOD Patches - Caranthir Tower Reborn" are not compatible and need to be updated. Everything else should be fine, but I am testing anyways to verify the updated patches. Edit: DynDOLOD Patches 2.21 now also contains scripts for Caranthir Tower Reborn 2.x. Obviously install the patched script version which matches the installed version of Caranthir Tower Reborn. Everything else works as before.

I agree, that the hammer is the most important tool for IT and other computer related problems. Looks great. Good job making the pre-rendered textures for the solitude farmhouses, too.

This is LOD for objects added by the mod to the Riften Town world in those exact positions. These new objects then get picked up by DynDOLOD to be added to the parent world Tamriel to match the outside view to the inside view. For older versions of the mod I already added exceptions to these oddly placed walls, so they are ignored for LOD. Looks like there is new plugin name now so the old exceptions do not match anymore. Open ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_childworldlod_Tamriel.txt in notepad. Find and copy paste this section: JKs SuperLITE - Merged.esp;00005A0B;WRWallCap01 JKs SuperLITE - Merged.esp;00005A0C;WRWallStrUp128 JKs SuperLITE - Merged.esp;00005A0D;WRWallStr01 JKs SuperLITE - Merged.esp;00000DBA;RTWall03Outer JKs SuperLITE - Merged.esp;00000DB3;RTWall05Inner Rename the plugin name to from JKs SuperLITE - Merged.esp to JKs SuperLITE - Cities.esp. Alternatively download the attached updated ini file that also includes the update for the new name JKs LITE - Cities.esp. Simply overwrite the existing one in ..\DynDOLOD\Edit Scripts\DynDOLOD\ DynDOLOD_TES5_childworldlod_Tamriel.7z

1. there is a _ too much. Just add glow_lod_0.nif to the full name, so the glow LOD becomes farmhouse02alt_mjbk_falkreathglow_lod_0.nif 2, I believe the mesh data itself is the same between the windows and the difference is just the textures? Then just update the texture paths in my existing glow_lod and copy to the new name. If you have any models with changed meshes/vertices just let me know. 3. The mini atlas LOD textures for Solitude/Whiterun/Markarth/Riften and Windhelm are pre-rendered and can not be copied together from single source textures with the simple methods build into xEdit/TexGen rules. If possible try to edit the source textures in an image program, or create your own with the help of screenshotting the new model in nifskope like you would for billboards.

1. Those are two different LOD models for two different full models. Use the one that matches the full model. walkwaycwall01.nif has the wall and walkwayc01.nif doesn't have the wall. So each has its own LOD model. 2. In this particular case it probably doesn't matter, but typically use the one from DynDOLOD Resources unless it looks completely wrong. The 02alt/02alt2/05alt/05alt02/06alt01/06alt02 versions are just a copies/nifconverted (removes export info) for the vanilla textures ETC. If LOD files DynDOLOD Resources has the exact same filename as vanilla, it is updated/fixed version for vanilla, so always use the DynDOLOD Resources one. If it is a "new" one that kind of already matches ETC additions While I just looked at it. Copy the *glow_lod_0.nif files to the new name of the LOD file you are creating as well. They are for glow LOD windows and will automatically matched to the main LOD file name you are creating without the need to be setup in the base record LOD levels or rules. In case the textures change, it usually just uses the same full model textures. You can check DynDOLOD_TES5_TexGen_noalpha_skyrimesm.txt for 'textures\architecture\farmhouse\farmwindowinterior01_m.dds' rule and copy that to the TexGen rules for the mod, but it is nor required. It just makes mipmap levels of the glow map texture be a bit brighter. Update the glow LOD windows too if you want to support that option.

AFAIK terrain bump is just about textures so that won't matter. If there are no other meshes\terrain\tamriel\*.BTR files in the load order (you probably would have to check *.BSA from the mods as well) then I would assume a mod changes the terrain height but does not provide updated terrain LOD meshes. That's a very common scenario with a lot of mods.

I see other people reported that problem as well. xEdit also reports additional errors that should be fixed as well. They probably were in a hurry to release before Christmas, which is no excuse for sloppy work though. I suggest to deactivate such mods while generating LOD. Keep a save before adding it, play the mod and once you are done with it, remove it and continue with that old save. Yes, 3D tree LOD is awesome It just needs a lot of RAM. Hopefully Skyrim SE will becomes usable for modding some time this year.

Looks like a mod changes the height of the terrain without updating the terrain LOD. The mod may ship with its own *.BTR terrain LOD files for the area, but maybe you are also using a high res terrain LOD that overwrites it. You could use CK or Oscape to generate updated *.BTR. Though it is a bit more involved than using DynDOLOD. Make sure to read the section 'Dealing with merged Mods' in the manual. If you used Merge Plugin it should have found and use the data files that were created when merging the mod. Check the log for the message. If all else fails the quickest option is to copy ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\DynDOLOD_TES5_campnewzainabesp.ini to DynDOLOD_TES5_mergedpluginnameesp.ini as explained.

We concluded that back in the day it probably was dynamic LOD and this time it is static LOD. Dynamic LOD references do not show in loaded cells (unless they specifically replace the original reference like water wheels or windmill fans for example). Dynamic LOD references check the state of the original reference only at the times when the dynamic LOD reference switches states e.g. the moment LOD turns on or off for cell. Typically, the state of the original reference can only be checked when its cell is attached. However, quest enabled/disabled items usually have a persistent enable parent marker that can always be checked. If you manually disable a reference, it naturally is loaded and when the cell detaches the state of the dynamic LOD reference updates accordingly.

It might be easier to just check in xEdit which mod adds references to cell 0, 0 with position 0, 0, 0. A mod that adds a reference in this cell also needs to contain the cell 000099A2 itself. So the mod will be in the overwrite list for that cell. Then CTRL+Click the Record Header / FormID row entry for a mod to update left pane to show the mod in the tree view, unfold tree [+] Bleakwind... [+] Temporary. The offending mod won't have many references to check. Typically you just remove the entire cell from the mod (right click [+] Bleakwind... in left pane - remove) It was dynamic LOD or you reverted the BTO file(s) for that area.

Fix the mod that adds the references and tell the author that the mod has wild edits so it can be fixed. Read the "How LOD works in Skyrim" section in the manual. If the LOD for this reference is dynamic, the LOD will also disable if the source is disabled. If the LOD for this reference is static, the LOD will stay. Static LOD are pre-computed *.BTO supermeshes. They have no reference. Update static LOD after removing the wild edit from the mod.

There are no LOD models for the mushrooms in the vanilla and I haven't created any for them. I am also not aware anyone else has. Have a look at DynDOLOD_Mod_Authors.html in the docs which explains the different ways how to "assign" LOD meshes to full meshes. I hope that will help you with that question. There are several methods and which to use also depends what type of LOD model are available. It also explains the best method to include pre-made object/tree LOD with your mod. If no LOD models exists the easy way out is to use full meshes for LOD. If the worldspace is small enough or the objects are not used a lot it may still work out performance wise. Since the mushrooms are animated and using glow them for static LOD may not work right without adjusting for static LOD limitations. One way to create static versions more suitable for LOD would be to use nifskope to remove all collision/animation/skin information and any NiTriShapes for the small features from the full models and rename them to *passthru_lod_0.nif However, the mushrooms also use an additional overlay Shape with an BSEffectShaderProperty to add additional glow which should preferably be emulated on the main shape with the BSLightingShaderProperty for performance reasons. It all depends on how many of these mushrooms are used and how big the worldspace is. Otherwise there is no way around to use something like 3DMax or Blender to create a decimated LOD model and be creative with the textures and the glow shaders to get close to the same glow effect. All of this requires some understanding of UV, textures, shaders and a lot trial and error to see what works in static LOD. In case the glow can not be made to look identical in static LOD, you need to use full models in dynamic LOD through mesh rules as explained in the documentation. This should be only done when we talk about a couple dozen of mushrooms within the Near/Far Grids what the mesh rule is setting. It would be still beneficial to remove collision/animation/skin and then rename them to *_dyndolod_lod.nif The pre-made dynamic LOD should not be included in the mod itself. Just the models/rules.

In regards to merging, you only ever need to worry about mods for which "custom rules" exist. Those are listed in the manuals 'Compatibility' section with a 1 As explained in the 'Dealing with merged Mods' section of the manual, "custom rules" for such merged mods are usually automatically applied to the merge.esp if DynDOLOD.exe can read the merge data typically created by 'Merge Plugins'. In any case, DynDOLOD.exe never changes positions of references regardless if they are merged or not - unless something breaks really badly, which should result in exception errors anyways. My gut feeling would be that there might a mod that changes the terrain height maybe and that the buildings are at the correct positions. Or that another mod adds landscape features like a dirtclicff. Hard to tell without screesnhot. So if you can't solve it from here, post screenshots.

Regarding the 3D snow cover of the farmhouses: You could 'copy & paste' just the snow NiTriShape with nifskope from the full model to the LOD model (source: right click NiTriShape, block, copy branch; destination: right click BSFadeNode, block, paste branch; update Name of NiTriShape to a valid string index). Most of it should just fit OK. If you know how to edit models with 3DMax or Blender, you could optimize it, but do not worry about the number of triangles too much. Since only a couple buildings are used in LOD, triangle count doesn't matter a whole lot. As long as the shape uses the full textures snow01.dds or snow02.dds you do need to worry about LOD textures or optimizing the UV into 0, 1 for the texture atlas. DynDOLOD.exe + LODGen.exe should take care of that while generating LOD. However, if you want to assign a LOD source texture, make sure the UV stays inside 0, 1 so it can be atlassed. That either requires use of 3DMax, Blender or can be done with LODGen.exe: See the ..\DynDOLOD\Docs\trees.ultra\tools\re-uv\ folder. Change 'tiled.nif' in re-uv.txt to the name of the nif which still uses full texture for UV, add/update LOD texture data in re-uv-miniatlas.txt (find more example at the top of ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_atlas_map_tamriel.txt - you can also find the lines for snow01/snow02 in that file) and then run re-uv.bat. Then check UV of new nif created in ..\DynDOLOD\Docs\trees.ultra\tools\re-uv\output\. It will use the LOD texture and the UV will be now within the 0, 1 limits. The reason to do this last part would be to create true optimized LOD meshes for CK/TES5LODGen/SSELODGen. DynDOLOD just does this step on the fly if possible.

First I suggest to have a look at ..\DynDOLOD\docs\DynDOLOD_Mod_Authors.html. Most of the things are already explained in there. I had a look at the file. I will describe the easiest process based on it. The current plugin uses a non-standard mesh file naming convention. The official content never uses the file name twice even if in different directories, especially if the content of the file is different. Generally DynDOLOD uses that fact to match unique full model filename to unique LOD model filename regardless of the path. This is not a big problem, it just means you need to define the correct LOD models specifically on each of the base records instead. The added advantage is, that this information will also work for for CK/TES5LODGen/SSELODGen. If you go with this option, the plugin name needs to be added to ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_mod_default_lod.txt so that DynDOLOD.exe knows to use the base record LOD level information instead of trying to match filenames. If you give me a heads-up before releasing your mod, I can release an updated DynDOLOD standalone that includes that update. Then you can require users to use a specific DynDOLOD version or newer and they would not need to edit some ini file. I suggest to give the LOD meshes unique names to separate them, because of the reason mentioned above. In case duplicate LOD nif filenames with different content exist in different directories, DynDOLOD.exe needs to ignore them, because the automatic filename matching can produce wrong results. Usually this works out because the default LOD mesh folders are scanned last and take precedence. In case of problems a path fragment needs to be added to IgnoreLODMesh= in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini. Again, if you give me a heads-up before releasing your mod, I can release an updated DynDOLOD standalone that includes that update. Then you can require users to use a specific DynDOLOD version or newer and they would not need to edit some ini file. Typically the best way to deal with re-texturing of the same 3D models is to use the alternate texture feature of the engine. However, since this is not the case here and the farmhouse LOD models use a pre-combined mini atlas anyways, it would not be that trivial either to add that info to DynDOLOD. I will leave that route for another discussion in case it comes up. In any case, this feature is not supported by CK/TES5LODGen/SSELODGen. In this case the easiest way is to create the new farmhouse mini atlasses etc. for the alternate textures sets with TexGen.exe. Read 'How to add LOD textures creation rules to TexGen' in DynDOLOD_Mod_Authors.html. Have a look at ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_TexGen_noalpha_skyrimesm.txt and for example find the lines that create 'farmhouselod01.dds' (lines #39 to #47 I think). Just copy those into a new instruction file with the name of the plugin, update the source and destination textures. For some of the re-textured models, LOD textures can not be created automatically (the citywalls). For those the only way is to maybe render (in nifskope - similar to creating billboards) and/or use an image program. Once you have created the LOD textures, copy the existing LOD meshes (use updated version from DynDOLOD Resources if they exist) to new unique LOD nif filenames and update their texture information to point to the new LOD textures. Then add the new unqiue LOD nif filename to the LOD levels of the base records. Do not hesitate to ask if anything needs more explanation. Since you mentioned 'Spice Of Life Forts' you can peek into its DynDOLOD folder and LOD folder for inspiration.

DynDOLOD modifies some base records by setting a flag to indicate it now has LOD. However that does not change the position of references added by mods. The Form ID of the reference is the one after "ID:" Enter this number into the FOrm ID field top left into xEdit.exe to bring up the reference to see which mods adds it or changes the position.

So this created a ..\textures\terrain\dlc2solstheimworld\trees\dlc2solstheimworldtreelod.dds texture that looks OK? Now just do the same as before, only select dlc2solstheimworld worldspace, but this time check 'Generate static LOD', check 'Generate DynDOLOD' and check 'Generate tree LOD'. Then click the 'OK' button. Does it run through now?

I still suspect one or more of those referenced files may be corrupt and you should try opening them in a image programs/viewer or reinstall them. Since you mentioned there is no atlas texture created to ..\textures\terrain\dlc2solstheimworld\trees\dlc2solstheimworldtreelod.dds - which should happens earlier when 2D tree LOD is generated - we can try probably do a quicker check with the logfile. But we need to make sure one is created by skipping over the problematic part: Start DynDOLOD.exe as always, go to advanced, only select dlc2solstheimworld worldspace, uncheck 'Generate static LOD' and uncheck 'Generate DynDOLO', only check 'Generate tree LOD'. Then click the 'OK' button. This should run through all the way to end pretty quickly and allow to Exit normally - not need to save anything. Once that happened there should be the logfile ..\DynDOLOD\Logs\DynDOLOD_log.txt we can look at. There will be lots of lines like <Note: DLC2TreeDeadShrubAsh [TREE:04019B16] LOD not found Textures\Terrain\LODGen\Dragonborn.esm\DeadShrub01Ash_00019B16.dds>which are normal. Then a good bunch of lines like DLC2TreePineForestAsh01 [TREE:04017F72] using LOD Textures\Terrain\LODGen\Dragonborn.esm\TreePineForestAsh01_00017F72.ddsand then eventually a line like [DLC2SolstheimWorld] Trees LOD Done.However, I expect some kind of error message to show as well since no DLC2SolstheimWorldTreeLod.dds was created with those billboards. If you can not find some obvious error message about some dds billboard just post that log or go though with checking the billboards manually and/or installing them again.

The content of DynDOLOD_TES5_dlc2solstheimworld_flat_textures_used.txt should reference textures files that look like this: textures\terrain\lodgen\dragonborn.esm\dlc2treepineshortheavysnow01_0003383c.dds textures\terrain\lodgen\dragonborn.esm\dlc2treepineshortheavysnow_0003383d.dds textures\terrain\lodgen\skyrim.esm\tundradriftwood01_000b8f53.dds Those are the files that you need to double check. Are you saying it contains Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds (which really does not make much sense when generating a texture atlas for Solstheim) or references to Textures\Terriain\DLC02\Trees ? Post its content if it doesn't contain only lines that start with textures\terrain\lodgen\*.*

This may be caused be file access problem when generating the texture atlas file for LODGen.exe. Delete all files in ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\*.* and try again (maybe a reboot is needed) Another reason could be some odd/invalid (billboard) dds texture that is needed while it is creating the atlas. So after trying again, open ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_dlc2solstheimworld_flat_textures_used.txt in notepad and verify each texture that is listed. By verifying I mean load it in an image program/viewer to check that it can be loaded and looks OK. Alternativly just reinstall those billboard textures from archive.

Crash = program closes or stops with an exception message (a non-recoverable or unexpected error) Freeze = programs stops responding in the middle of something I am assuming the last screenshot shows the freeze, while the first two screenshots show normal operation before that happens. If you set FasterBase=0 in DynDOLOD_TES5.ini, DynDOLOD.exe should not ever freeze while building the list of base elements. Please double check the setting. In any case make sure that none of the plugins has any errors left in them by checking them all in xEdit. See this video for help If it freezes while building a list of base records it can not continue to scan the worldspaces and start a LODGen.exe process. So the LODGen_Tamriel_log.txt you uploaded must from an older generation when it worked. I suggest to clear the log folder before the next run so we are not confused by old logs.

It is not clear what you mean by "first three" checkboxes. When doing the two runs for Open Cities it will ask to save the esp. Make sure you also selected a worldspace. Check the log for errors if it stopped prematurely.