PRieST

Yeah you're right - hadn't said it, but CRC32 was identical as well. Thanks for looking into it.

@sheson I think you uploaded the wrong version to Nexus. I wanted to exchange the new DLL (Alpha 27) - but the two files had the same size and edit date (10.05.24) as the old ones and so windows suggested, because they are identical, to skip it. This happened the first time for the DynDOLOD NG DLL and so I assume something went wrong during the upload. Edit: Same for the files on MEGA This a comparison between 25, 26 and 27 (downloaded from MEGA) https://ibb.co/J2QKn1G

Thank you (for the explanation), will use that nif until next release.

I have a question regarding the DynDOLOD resources. Specific it is for this mesh: "\meshes\lod\windhelm\whouterwallstatue01_lod_0.nif" I am using some different texture replacer (Noble Skyrim HD) for windhelm and one of them is coloring the statues more brownish. Full Model of WHOuterWall01.nif: https://ibb.co/vPw9v6t LOD Model WHOuterWallc01_lod.nif: https://ibb.co/xsscLy0 LOD Model WHOuterWallStatue01_lod.nif: https://ibb.co/9bLJCDs How exactly could I change (with nifskope or a mesh rule) that the statue lod is using the proper lod texture (maybe not from the atlas, because it's not matching - well way too white)? Or does it even get used? How could I find that out? Because if I am looking at the created .bto files, there is no statue alone.

35k/year...holy... that's kind of a statement... OK I guess that's it then. Glad I just finished this and a few other things earlier.

@sheson Did what you suggested with Simplygon and the UV stuff. This is now the result of the same *32*.bto file (it's using textures from the atlas now as supposed to be). The mesh itself is a little bit broken, but for the map it's absolutely fine: vs. the old model: Just wanted to give you/all other people here the info. Of course best practice would be to reduce the overall polycount next, because you won't need all the little structures for the LOD-model at all - but I haven't worked on that, yet.

I was already working with Simplygon via Blender, but haven't recognized the UV tiling feature. Will take a look, thank you. btw: Yep, renaming the BSTriShapes solved the issue as you said.

Oh, ok, it's because of the naming. Now that I know that...this should be something I need to consider for the other 'textures not match' messages :/ I'll see if I can even further decimate the model myself. But wouldn't this one not ok for level 1 and a more optimized version for level 2 - and if I am correct renaming the mesh to *_lod_1.nif and *_lod_2.nif would than apply it correspondingly? I thought the new version only changed the NiTriShapes to BSTriShapes - will use the new version now.

Hey, I don't know if this is an error done by DynDOLOD or a usererror of myself. I installed Unique Wooden Bridges - Base Object Swapper recently. Because I wanted to reduce the plugin count on my side I merged everything into my own .esp plugin together with the corresponding swap file. The mod is also shipping a LOD model for the bridge. During the new generation of DynDOLOD I saw this message - which is also mentioned in the summary: Warning: Textures do not match for "Bridge01:1": textures\architecture\farmhouse\stonewall01.dds in woodenbridge01.nif -> textures\architecture\farmhouse\woodwalkway01.dds in woodenbridge01_lod.nif for LittlePatchFixes.esp EastMarchBridge01 [STAT:68005DE7] Full Model: https://postimg.cc/BjDN32vM (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds) LOD Model: https://postimg.cc/94hbQzRV (textures\architecture\farmhouse\WoodWalkway01.dds / textures\architecture\farmhouse\WoodWalkway01_n.dds) In a corresponding .bto file: https://postimg.cc/sB4cQy7W (textures\architecture\farmhouse\stonewall01.dds / textures\architecture\farmhouse\stonewall01_n.dds) This is the corresponding record in xEdit: https://postimg.cc/D4ryFCt7 Also not inside the DynDOLOD_SWAP.ini. The only thing I can assume from this is, that the texture for the LOD model gets not applied correctly. Or do I have to set up a specific mesh mask rule for the wooden bridge? Here are the logs: Logs on MediaFire

@sheson Have you seen this mod/issue on nexus? Is this something you're aware of, if this really is a thing? Missing Windmill Fix I had this issue in the past a few times while I was testing my DynDOLOD generation via COC from main menu and so the windmills were missing. If the game is started normally or DynDOLOD gets updated/made from scratch in an ongoing save (clean save method) I think this never happened. I don't know if my logs would help in this case, because I don't have this issue on my end right now - just wanted to inform you about the 'mod'.

With the test version DynDOLOD was finished in 20 minutes without any errors. Exchanging the exe file you provided was the only change I made.

As said, this never happened before and also not with alpha 165. I see that it runs out of memory. With the regular version one LODGen process used up to 24GB of ram alone. I think the 'run out of memory' was just at that time of the atlas creation, this didn't happened another time I ran DynDOLOD, so it was a one timer (because of tha ram usage spikes). I am testing the test version right now. It's still running, but I can tell, that the generation of the bto files is fast again and the ram usage stays quite low. Also it seems I am not the only one having these problems:

Edit: I wrote this, while I started a new generation for the logs and got this message: [Window Title] DynDOLOD [Main Instruction] Error: OpenGL: 2610CB97 framebuffer incomplete attachment. [Content] Click on this link for additional explanations and help for this message Clean install the latest recommended/WHQL (not optional and not beta) graphics drivers only without any bloatware. If the issue persists, posts a problem report on the official DynDOLOD support forum. [Exit DynDOLOD] [Footer] Online Help | Support Forum | Copy message to clipboard This is new and never happened in the past even if I had one or two firefox tabs open. LODGen is still running (very very slow) - may be because I didn't closed DynDOLOD.exe. I am using plain nvidia drivers without anything else and also all of my 32GB ram were maxed as well as 100% CPU usage. I have no comparison to earlier generations, but this seems a bit odd, I don't think DynDOLOD/LODGen used all of my ram in the past. Here are the logs to this point: No Bugreport.log because I had to manually kill DynDOLOD (it just stayed open). DynDOLOD/Debug log __________________________________________________________________________________________________________________________ I know this may be a bit of not so good report, but somehow with alpha 166 the LODGen process is taking ages. In earlier versions DynDOLOD in whole was finished in about 30 to 40 minutes (including generatin Occlusion.esp). But now not even Level 4 *.bto of Tamriel are finished - infact it were only about 30 files. I could provide you the logs to this point, as I don't want to wait hours before DynDOLOD is finished, as this is a new behavior. This is written in the cmd window: ============================================================ Skyrim/Fallout Object/Terrain LOD Generator 3.0.21.0 Created by Ehamloptiran and Zilav Updated by Sheson Log started at 01:08:17 .NET Version: 6.0.26 Game Mode: SSE Worldspace: Tamriel Fix Tangents: False, False, False, False Generate Tangents: True, True, True, True Generate Vertex Colors: True, True, True, True Merge Vertex Colors: True, True, True, True Merge Meshes: True Grouping: False Remove Faces under Terrain: True Remove Faces under Water: True Remove Faces Z-Shift: 10 Use HD Flag: True Ignore Materials: False Alpha DoubleSided: False Default Alpha Threshold: 128 Use Source Alpha Threshold: False Use Backlight Power: False Use Decal Flag: True Specific level: No Specific quad: No Max Level: 32 Output: D:\DynDOLOD\DynDOLOD_Output\Meshes\Terrain\Tamriel\Objects\ Using UV Atlas: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt Using Flat Textures: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_FlatTextures.txt Using Alt Textures: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_AltTextures_Tamriel.txt Generating object LOD meshes for worldspace Tamriel Reading D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_LODGen_Terrain_Tamriel.bin Threads: 20 Concs: 10 and after that the correspoding finished files (excerpt): Finished LOD level 4 coord [44, -20] [211422/182082] Finished LOD level 4 coord [-12, -12] [351088/297749] Finished LOD level 4 coord [24, -4] [493912/446584] Finished LOD level 4 coord [-32, 28] [740072/723720] Finished LOD level 4 coord [16, 8] [944526/923257] Finished LOD level 4 coord [36, -24] [126721/96119] Finished LOD level 4 coord [40, -20] [210528/173473] I didn't change anything big since the last generation with alpha 165 which could result in such long generation times. I looked at some created bto files and they also don't seem to be extra large or complex in comparison. Maybe it's a fault on my end with too many high poly assets, but if this is the case I can't even tell which ones are the culprit.

https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds

Ah, didn't knew this ws already documented. Interesting I've never seen this before, as it should've been there forever. Good to know and thanks for the reply.

This may be nothing too much of an issue, but I noticed the following when DynDOLOD was generated with Alpha-165: I searched my plugins for erros with xEdit and there are a few records mentioned in DynDOLOD.esm Checking for Errors in [17] DynDOLOD.esm [01:43] Tamriel_Underside [MSTT:17046337] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] DLC2SolstheimWorld_Underside [MSTT:170463BF] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] MarkarthWorld_Underside [MSTT:170463C0] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] SkuldafnWorld_Underside [MSTT:170463D6] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] Sovngarde_Underside [MSTT:170463EC] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] DeepwoodRedoubtWorld_Underside [MSTT:170463F5] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] DLC1HunterHQWorld_Underside [MSTT:17046401] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> [01:43] DLC01FalmerValley_Underside [MSTT:17046459] [01:43] MSTT \ Record Header \ Record Flags -> <Unknown: 2 $2> A screenshot from one of the records in xEdit: https://ibb.co/JzzMbT4 LogFiles from DynDOLOD generation There was nothing noticable during the generation itself and in the game also eveything looks fine. I assume the wrong flag gets set - or is it an 'issue' with xEdit (as you can see I am on version 4.1.5b) because I 'can't' see what is behind this flag?

Yes, this is of the 'new' 'partial form' flag. If the worldspace itself doesn't need to be edited (in which case we are here) you can set this flag and so the worldspace data doesn't get overwritten by DynDOLOD.esp/Occlusion.esp. That's why you also see no records inside these two plugins for the worldspaces. That's a feature which was forever in the engine, but only recently included in xEdit and now DynDOLOD makes also use of it.

Can confirm, it's fixed, thank you again.

Ok, will give it a try, thank you. What was the issue if I may ask? For me it looks like the display between uLargeRefLODGridSize 5 -> 11 was 'switched' /the wrong way round?

(Maybe a dumb question, because I could just have tried both ways) With or without quotation marks? Because with it I just get "unknown type" https://ibb.co/tbj0kgm But I checked, if I get the default SkyrimPrefs.ini, what the value is and it is set to 5 (which is working). In my case setting it higher as 5 it breaks somehow the LOD display. Generation was fine, but the display ingame is the culprit. https://www.file-upload.net/download-15241320/Tamriel.4.4.-8.7z.html Definetly that one (the same spot jus looking left if you compare it to the screenshots). But as far as I can tell the .bto looks absolutely correct. Edit: Comparison between uLargeRefLODGridSize=5 https://ibb.co/wR6FT1M https://ibb.co/Bs8cYRd uLargeRefLODGridSize=7 https://ibb.co/t3hRkbP https://ibb.co/dpK5Xy4 uLargeRefLODGridSize=9 https://ibb.co/Nr2PX9C https://ibb.co/0K1tYgh and uLargeRefLODGridSize=11 https://ibb.co/kXKDCZV https://ibb.co/Bcs1jxd

The culprit is this in Skyrimprefs.ini under [General] uLargeRefLODGridSize=11 Without that line everything looks fine. But why? This wasn't a problem with earlier alpha versions. This is from the DynDOLOD_SSE.ini: ; Because Bethesda simply does not comprehend people are modding exterior worldspaces ... ; set to 1 if uLargeRefLODGridSize=5 (value of uGridsToLoad) in SkyrimPrefs.ini, do this if it is certain that the large references system will not be used, so that no DynDOLOD.esm is created ; set to 0 if uLargeRefLODGridSize>5 (value of uGridsToLoad) in SkyrimPrefs.ini IgnoreLargeReferences=0

But than I'll have to figure out which setting is messing up the LOD loading for LOD 4, I don't have so much under [LOD] section which looks odd.

So I went in the game with the default ini, and yeah I am surprised, because this is the result (and compared to the other screenshots, there are even more trees visible..hm): https://ibb.co/568XKXv This is with my ini settings, so maybe there is something wrong I'll have to check, but as I said even with earliere alphas from DynDOLOD it worked, because the only setting I touched was the setting for particles: https://ibb.co/ncvSMZX And this again is with my ini settings, but without the DynDOLOD DLL NG loaded: https://ibb.co/MfHTsJG I meant the MCM, that it looks different now than I was used to, nothing special. Of course, will get rid of it the next generation - just forgot about it to be honest. I'll give this another test and see what the results are.

Disable Occlusion.esp didn't do anything to this. I also looked at some of the created .bto files, they look quite good I checked 'Tamriel.4.4.-8.bto' as an example, because there are all trees missing when I am at WhiteRiverWatchExterior03 and looking down (good place to test DynDOLO IMO). The bto file itself looks absolutely fine. I'll see what happens if I use dafault ini of skyrim - but I have to tell you, that I didn't mess with them since ages. I'll also try and deactivate some SKSE plugins, maybe there is something odd happening (in the past I had a very confusing error with Dynamic Things Alternative, but that's not the case this time, but who knows. Ok, that's why it's looking different. Kind of forgot about that plugin and with the Large Reference Bug Workaround it might be obsolete. This was an old approach from me to solve the large reference bugs with this method from the help: https://dyndolod.info/Help/Large-References Edit: I checked what happens, if I disable DynDOLOD.esp, .esm and Occlusion.esp and output active, result was: The whiterun castle was complete there, where it wasn't before. Still, the chunk with the trees (where I checked the .bto file) was 'empty'. With also the SKSE plugin deactivated, all LOD are there, but also the fullmodels I think, because there is massive flickering. Without the SKSE plugin, but all DynDOLOD plugins active I get an papyrus version mismatch error (absolutely obvious), less flickering (I know, there is something not working as supposed to be, thats also obvious) - I assume it's because of LOD and Fullmodel renderd at the same time, but the whiterun castle looks good and also the LOD 4 part is there and not vanished as it was, while the DynDOLOD NG SKSE Plugin is active. I only can assume that it's related to the plugin, but it looks like it is. I'll mess with some SKSE plugins, deactivate a bunch and see, if there is any difference -> nothing found there.

I think something has borked with my last generation with DynDOLOD 161. I went via coc whiterunexterior16 from main menu in the game, same result if I do coc riverwood and walk straight to whiterun by foot. I only can see stuff which is near to my character and the far away (fargid?) lod. Trees for example aren't present, only when I get closer the full models are loading, only billboards are in distance. As you can see on the screenshots further down, first the whiterun castle lod is viewable, if I get closer it vanishes (no step in between) and only If I get close enough the full models are loading. You can also see that there is no difference if LOD is active or not (tll command). Can't tell what happened here, everything looked fine during generation. Here are the logs Here are some screenshots: https://ibb.co/0BsxnQV https://ibb.co/267MjVw https://ibb.co/qkwQcs1 https://ibb.co/4mPR2pC https://ibb.co/xSpfsGd https://ibb.co/wyhM20g https://ibb.co/F6Yr8vR https://ibb.co/mcTbTbx https://ibb.co/DtZzdR3 https://ibb.co/0Dk3m16 And this is just an example. I had no (critical) errors during generation nor any crashes. Or do I have to start a new game to get everything to work correctly? In the past it worked even if you coc from main menu. Oh and is it correct, that the some points from the MCM are missing e.g. where you set 'NetImmerse Override' on/off? Haven't read anything regarding this in the changelog. https://ibb.co/brBLH9W https://ibb.co/cr5HBR9 https://ibb.co/Y7kV14q