sheson

See https://forum.step-project.com/topic/14565-help-me-to-understand/?p=240781

As explained in the TexGen manual, pre-rendered LOD textures can not be automatically created from single full textures. This is a bit experimental and doesn't work for pre-rendered textures like the town LOD textures, distant mountain peaks or glaciers for example. Having a look at the object LOD source textures like textures\lod\wrbuildingslod01.dds for town buildings and comparing them to tileable landscape textures makes it clear. The town LOD textures are rendered from the full models and not a simple derivative of a full texture. They were then processed with an image program to create the final LOD textures. Compare the images posted by ntluan_vn to simple LOD textures that are directly derived from the full textures. The difference is obvious. Pre-rendered textures are side views of complete models. If you have a mod that changes the full textures for these models, the mod should also include updated pre-rendered object LOD textures. https://forum.step-project.com/topic/14565-help-me-to-understand https://forum.step-project.com/topic/15228-having-trouble-getting-correct-textures-in-lod

Obviously, post the crash log from NetScriptFramework. In the meantime read the FAQ entry about CTD and the included readme.

The changes from the test version are now included in DynDOLOD 2.87

If no model is defined for a LOD level, nothing will show for this object for that LOD level. It does not matter if the same LOD model is used for different LOD levels. The linked reference with the keyword is for a group of references that are part of a LOD model for the higher LOD levels. For example, a group of buildings standing next to each other each have an individual LOD model in the first LOD level. In the higher LOD levels, the entire group of buildings are depicted by the LOD models defined on the base record of the the linked reference.

It seems you have a problem enabling mods/plugins correctly with the mod manager you are using. Make sure the output was properly installed as a mod and the plugins have been enabled. Beyond that, this obviously is not a problem with DynDOLOD and you probably should ask for help on the MO2 forum/discord. Make sure that the game is not installed in protected Windows folders like Program Files x86. Make sure that MO2, tools, DynDOLOD, anything else is not installed into Game, Steam or protected Windows folders. Make sure that antivir or other crapware is not interfering.

You have a customized load order and expect others to spend time watching videos in order to find out if maybe something could be better without saying what the supposed issue is. I have no idea what you expect or want to improve.

Use a real mod manager. If you just check what files types a mod contains, then there is no confusion what needs to be enabled for terrain LOD generation only. As already explained, generally mods containing object LOD meshes and textures should not be disabled after LOD generation. "Lod Pack for DynDoLod (all versions)" is such a mod. Maybe the 3rd party STEP guide has a good reason, I have no idea. Otherwise the order of things seems OK. You also posted 3 videos. Am I supposed to look for something?

The STEP guide is a third party modding guide. I do not know what the mod "(TEMP) Magestic Mountains - LODGen." is or what it contains.

Cathedral landscape is terrain LOD. Terrain LOD textures are generated from the full landscape textures in textures/landscape/*.dds. Cathedral landscape has special full landscape textures that fake grass for terrain LOD texture generation. Naturally those textures are not supposed to be used in the game. Where do you find official instructions for Majestic Mountains that say the object LOD meshes or textures should be disabled after LOD generation? Stuff in meshes/lod/ and textures/lod/ are used for object LOD generation and should typically not be disabled. We call those textures single/miniatlas object LOD textures (which is what TexGen updates) that are combined onto the object LOD texture atlasses.

It is not clear what you mean by "this". The entire mod? No of course not. Object/Tree LOD is generated for the plugins and assets (meshes and textures) currently in the load order. If the load order changes, then the LOD will not visually match anymore. Specifically, as already explained, meshes and textures used for object LOD generation should not be disabled after LOD generation. If you want to disable something because it does not fit or work well, it should not be part of the load order anymore while generating LOD.

No. The manual does not include instructions for the million things not to do. Textures overwriting other textures does not cause z-fighting. If a mod includes special landscape textures only for terrain LOD texture generation, then those textures obviously need to be disabled again. If a mod includes object LOD assets (meshes or textures), then those need to stay active after object LOD generation as they might be used directly as well.

It is not really clear what you mean by HD LOD Resources Pack as there is no such download file.

Generally full models should not be used for LOD in a play-through. Make sure to only include billboards for trees that are add/ or modified by the mod.

Simple logic applies: There are vanilla normal map LOD textures that will be used if they are not overwritten. It is very likely that the updated diffuse LOD textures does not change what they actually depict - just their color, thus the normal map does not need updating. Simply looking at the textures in an image viewer should tell you everything you want to know.

Never assume. If LOD models create problems, the obvious first troubleshooting step is to identify by elimination what LOD models are causing it. Do not make assumption. Missing textures is an issue that should be fixed, obviously. Double check the shader settings, textures or material files settings. Then find the LOD model in the created BTOs and what shader settings remained, because LOD only supports a small subset and typically all unsupported setting are removed. Use the Specific chunk option to only generate specific BTO files. A properly build and setup computer should have no problems when it is being used.

As you can see, the base record form id is part of the billboard filename. If compacting changes form ids of tree base records, the billboards filename need to be updated as well.

Note that new tree references added by ESL flagged plugins can not have traditional tree LOD. DynDOLOD will automatically do tree LOD in object LOD for them. Modifying existing references is fine. Make sure to only include tree LOD billboards for the trees that are changed or newly added by the mod. Do not include tree LOD billboards for trees that are not changed or added by the mod. The tree LOD billboards filenames in textures\LODGen\fantasticforest.esp\ do not match any of the new trees added by the mod. The tree LOD generation log shows lines like these: <Spook_TreePineForestLarge01 [TREE:FE001800] billboard not found textures\terrain\lodgen\fantasticforest.esp\treepineforest01_large_00000800.dds> <Spook_TreePineForestLarge02 [TREE:FE001802] billboard not found textures\terrain\lodgen\fantasticforest.esp\treepineforest02_large_00000802.dds> <Spook_TreePineForestLarge03 [TREE:FE001804] billboard not found textures\terrain\lodgen\fantasticforest.esp\treepineforest03_large_00000804.dds> <Spook_TreePineForestLarge04 [TREE:FE001805] billboard not found textures\terrain\lodgen\fantasticforest.esp\treepineforest04_large_00000805.dds> <Spook_TreePineForestLarge05 [TREE:FE001806] billboard not found textures\terrain\lodgen\fantasticforest.esp\treepineforest05_large_00000806.dds>The "dead" versions of the tree base records have no objects bounds. You need to generate them with CK.Tree LOD Billboard Creation : Start to Finish Make sure to only include 3D tree LOD meshes for the tree that are changed or newly added by the mod. The file naming convention and other things are explained in docs\trees.ultra\tools\DynDOLOD_CreateStaticTree.html Basically, a 3D tree LOD model is a static model version of the tree, preferable with less triangles (decimated or trunk replaced by "billboard" for example) and UVs within 0.0 and 1.0. We discussed some of that in the past https://forum.step-project.com/topic/15258-following-createstatictrees-workflow

Thanks for the log. Looks all good now. Yes, you can use the generated output in your playthrough.

https://mega.nz/file/wdgXHADY#i5xGSdIVikKPiolJP58WD1mjSDNNDHBBRk6iZ65ZvQo Thanks, another test version. Might run through this time. Either case, upload the log with debug=1 please.

FAQ: Game: Out of place objects / floating objects / flickering full models A: If LOD was generated for a different load order generate LOD for the current load order. A: Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If problem goes away, the updating of an existing save game with old DynDOLOD.esp went wrong. Follow instructions how to update save game with a new DynDOLOD.esp. RTFM, watch the video or check DynDOLOD SkyUI MCM. The clean save routine can also be redone with the same plugin to reset everything. A: If the load order had script lag and deactivating/activating from the DynDOLOD SkyUI MCM main page does not reset out of place objects, do the clean save routine where "old" and "new" plugin are the same. Consider generating less demanding dynamic LOD, see 'Performance' section in ..DynDOLOD\Docs\DynDOLOD_Manual.html A: Wild edit added by a plugin. Check the DynDOLOD log for messages about wild edits. Use console in the game and click on object to retrieve the form id. Look up the form id in xEdit and remove the reference, clean plugin afterwards. Notify mod author. If object is added by DynDOLOD.esp, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this object originates. A: Deleted record by a dirty plugin. Check the log for messages about deleted references by dirty plugins. Clean all UDRs and ITMs from dirty plugins. A: Sometimes LOD objects are placed on top of other objects without LOD and thus appear to float in the distance. Use mesh rules so that the object has no LOD or that the other object also has LOD. A: Game engine limitation. If the game enables objects that have static object LOD, the entire static object LOD for a cell may briefly show with the full models at the same time. Since now more objects have LOD this might be more obvious than before, especially while playing the intro. Consider installing the generated LOD mod after completing the intro. A: If the problems is stuck object LOD in Whiterun after fast travel, change Distant Object Detail on the View Distance tab of the Advanced options of the games launcher from Ultra to High. Alternatively try just slightly changing the value fBlockLevel0Distance=60000 in SkyrimPrefs.ini to 57000. 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. A: Flickering textures (full and LOD model showing at the same time) in the LOD area outside the active cells in Skyrim Special Edition and Skyrim VR are caused by plugins triggering the large reference bugs as explained in ..DynDOLOD\Docs\DynDOLOD_Manual_SSE.html. Verify if the problem goes away by setting uLargeRefLODGridSize=5 in SkyrimPrefs.ini. A: If the problem is stuck object LOD in loaded cells, it can be caused by uLockedObjectMapLOD=32 in Skyrim.ini. Looks a lot like large reference bugs to me.

https://mega.nz/file/NRhgFbBC#SlpyU3hnrYZ_UZ8EF1BjlH5dzBmnXwALf1tUhLBFQ0I Replace DynDOLODx64.exe with this version and run again with debug=1. It might run through or have same error, but will print more information for me to look at.

Look in the BTO if the mesh for the object is in there. If a source texture is greater than the Max texture size it won't be put on the atlas texture. The shape/shader in the BTO will use the source texture directly. The atlas will try to have the smallest possible size to fit all the textures that can be put on the atlas. There is no cap. the BSMeshLODTriShape should not matter, it should use the full version of the shape. You are telling a story. Providing example files/screenshots etc. would be better.

Scroll down the 2nd screenshot to also get the rest of the record. Upload the the smashed patch.esp if you can.

Great. Open the entire load order in xEdit. Type in the form ID 0001A280 into the FormID field top left and hit enter. In the right window it will show the record data and all plugins overwriting it - if any. Scroll to the very right in case there are many overwrites. Unfold every [+] collapsed row, then make screenshot(s) so that we can see all of the record. Repeat for form ID 0001A26F