Blackread

Excellent, thank you.

I haven't managed to complete the troubleshooting for the on load crashes yet, still working on it. But I wanted to ask for some clarification about how texture transparency works with LODs. The dyndolod website states the following: If the full model texture uses alpha, will the parts of the texture below the threshold always be transparent, even if the LOD model in question doesn't have a NiAlphaProperty in the block that uses said texture? So if I don't want the texture to be transparent at all, is the only way to make a dedicated object LOD texture without alpha?

Hello sheson, I'm seeing crashes on loading a save with the latest DynDOLOD 3 Alpha. The basic sequence leading to the crash is: Make a save in an exterior location -> Go somewhere else -> After a while load the save -> Crash. Here's a video of a repeatable test I deviced. It looks a bit odd, but the crash does happen during normal gameplay too. It's uncut footage including all loading times, the main test starts around 2:25. Here's the top part of the crash log produced for quick examination: Full crash log along with DynDOLOD logs here: https://mega.nz/file/sPlDHADb#eP0vryOYQeVPwuYiHEDCT_DoPAFc02nXDmvKr3bPqUA Another user also gave similar reports about crashing on load with this crash log: https://pastebin.com/vgx3Kiz7 I've also seen this crash at 902691 but the one at C072DF is a lot more common for me. The other user said that after regenerating LODs without Large Ref Bug Workarounds they were no longer crashing, but I haven't verified this myself. I have however been unable to replicate the crash without a DynDOLOD output. Edit: I also noticed that while the link to the DLL NG download on dyndolod.info says Alpha-15, the downloaded file is actually Alpha-14.

One more related question, what are these h and l suffixes on the files? Do they stand for high and low, or something else?

Here: https://mega.nz/file/ZGlHnDYZ#8Yu6xGt9aEVE6di0UEedQJSv7Sz7qj9lpgAAilIixhs

This is what DynDOLOD is telling me: If I'm reading it right, it's trying to match xxx.nif with xxxsnow_lod_[0|1|2|3].nif even though xxx_lod_[0|1|2|3].nif is also present. Logs: https://mega.nz/file/sLNWAKSL#MkTheTPb1ywwjcndCPjcp4TwWiGrHTKXYn8FA2w-Y-w

Is there a guide on how the *snow_lod_x.nif files are matched to the full models? I read through the Mod Authors page but couldn't find mentions about them. Also, do the snow lod models support the same CRC system as the "normal" lod models? If I have, say, tundrastreamend01_1234ABCDsnow_lod_0.nif, will that be matched with a tundrastreamend01.nif with CRC32 1234ABCD whenever it's considered "snow", or with every use of tundrasteamend01.nif?

The test version fixed the stuck glow LODs.

The swap file generated by DynDOLOD is not working. Looks like Base Object Swapper is strict about the letter case: the _SWAP suffix needs to be all upper case, and the file generated by DynDOLOD has it in lower case. Pictures, in order: 1. Fence in WhiterunWorld as is 2. Fence in WhiterunWorld after renaming the file to DynDOLOD_SWAP.ini 3. Original fence in Tamriel. EDID of the fence copy is skyrimesm_0627B3_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD There's also this bit of road sticking through the Whiterun front gate: 1. Road in WhiterunWorld 2. Original road in Tamriel (the gatehouse was disabled when taking the screenshot) EDID of the road copy: skyrimesm_069818_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD Lastly the dark elf lantern glow LOD has made a return. I didn't see them with Alpha-134. EDIDs, respectively: telmithrynesp_078BF5_DLC2SolstheimWorld_DynDOLOD_OBJECT telmithrynesp_040FF2_DLC2SolstheimWorld_DynDOLOD_OBJECT Logs: https://mega.nz/file/YbU33bCS#orQb99fQmxXAdE3TPJ6BRRZRxtbBVdFkyMogM432rqg

Sounds like a good solution, thank you. I also have a suggestion of a few lines to be added to \DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_ChildworldMatches.txt to fix a few issues when copying SolitudeWorld with NoCellsWithNAVM=0: The details for the issues are at the bottom of my comment here: I generated Tamriel LOD with these additions and the end result looked good to me.

Here: https://mega.nz/file/NGtgRJDb#6_qQlqMbMp98j0O2zmDZJV_s844_1KJenJmBXxVccHA I only included the Tamriel.4.-44.0 and Tamriel.4.-44.-4 blocks, I assumed you didn't want the whole of Tamriel.

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4. First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it. Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example: Caption for the pictures in their order of appearance: 1. The dock copy as seen in the child worldspace (SolitudeWorld) 2. The dock LOD as seen in the child worldspace 3. The original dock as seen in the parent worldspace (Tamriel) 4. The dock LOD as seen in the parent worldspace EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4 The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Very true, and I have barely any mods modifying the exterior areas of cities, with Solitude being the exception, so my load order is fairly easy on that regard.

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.

You are right, that is the downside of the fence mod. But even if it did rename the meshes (which I of course could do myself too), I wouldn't have matching LOD assets for the new fences, so in a way I'm content with using the same LOD models for all of them. They are close enough that I haven't noticed any discrepancies so far. I already tried regenerating the LOD for Markarth without the flag and it did indeed solve all the issues. I'll try with your suggested edit to the cell record next. I took some comparison pictures of the evermore location in both worldspaces, I think they are from the same camera coordinates. They are indeed quite different from each other. In my regular setup I use Majestic Mountains and as such can't click on the mountain meshes in the console, as they have a multipass moss/dirt shader on them. Because of that the pictures below were taken with majestic mountains disabled. I "excavated" the objects by disabling other objects around them, I believe this is the full model which the LOD is originating from. Pasting my last edit to the previous post here in case you missed it: Update: I tried hiding the landscape as you suggested, but force hiding the quads made no difference in the xLODGen terrain LOD output. I instead made a plugin with which I dug a "hole" (or a valley) into the hill where the mine entrance is, that got rid of the terrain LOD in the tunnel, and the underside too. I also tried setting NoCellsWithNAVM=0 for Riften and Solitude. It worked a treat, the missing objects were added in without any adverse side effects as far as I could tell. Edit: Nevermind, there are some clipping mountain meshes in Solitude. I regenerated Tamriel without Majestic Mountains so I could take screenshots and upload logs. EDIDs for the pictured objects respectively: thegreatcityofsolitudeesp_0147DB_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD thegreatcityofsolitudeesp_0136D6_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD thegreatcityofsolitudeesp_0136D4_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD thegreatcityofsolitudeesp_00C4AE_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD Logs: https://mega.nz/file/df1xlCja#wuri-b8_PihDzhHkFav5Mt6y6YOSF4HPGE4JVqhHEBA

Alright I gathered up the information. Here are first the pics for the fences: The EDID for the copy is skyrimesm_0627B3_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD. The mod swapping the fences is Fences of Skyrim and the fences are swapped by their reference IDs. The Cidhna Mine entrance information: Cell: -43,0, CELL: 20EED~Skyrim.esm, LAND: B2550~Skyrim.esm Objects: Tamriel.4.-44.0.bto, Tamriel.8.-48.0.bto, Tamriel.16.-48.0.bto Terrain: Tamriel.4.-44.0.btr, Tamriel.8.-48.0.btr, Tamriel.16.-48.0.btr, Tamriel.32.-64.0.btr I looked at it a bit closer ingame and noticed there are three things happening. First is the underside mesh, which is visible when coming out of the mine (single-sided). The EDID for the underside is Tamriel_Underside_DynDOLOD_NOLOD. The second is a single-sided LOD object which is visible from the outside, this is what can be seen in the first image I posted. I suspect this is the terrain LOD. The third one is a double-sided LOD object sitting behind the single-sided one, which I suspect to be a mountain from the object LOD. I suppose at least the underside is a side effect of making Markarth use the Tamriel LOD. I also looked at the terrain and object LOD files, but I'm not really sure what I should be looking for, or how to compare them to the loaded cell. Edit: I checked the LOD files again and in the object LOD files there isn't anything in that spot in any of them, so the double-sided LOD object can't be a mountain object after all (or at least not from one of these). In the terrain LOD there obviously is the slope up the mountain, though I'm not sure how to relate it to the loaded cell. /endEdit Edit2: Setting Markarth to not use LOD data eliminated all the LOD objects. However, the underside is still there. But since I had the flag enabled while generating LOD maybe I just need to regenerate without the flag? Evermore information: Cell: 14,-4, CELL: DF8ED~arnima.esm, LAND: n/a Objects: arnimaEvermore.4.12.-4.bto, arnimaEvermore.8.8.-8.bto, arnimaEvermore.16.0.-16.bto Terrain: arnimaEvermore.4.12.-4.btr, arnimaEvermore.8.8.-8.btr, arnimaEvermore.16.0.-16.btr, arnimaEvermore.32.0.-32.btr With this one I also noticed the LOD object is double sided. There are no terrain LOD files under those names in my mod list, and there are no object LOD files generated by DynDOLOD for this worldspace either. However, there are these bundled with the original mod: But the file names don't match the ones shown by the DynDOLOD MCM. Edit: I checked the meshes but none of them seemed to match what was seen ingame. Moreover, none of the objects in those meshes are double-sided, so it doesn't look like it could be any of them seen there. Edit2: Looks like setting Evermore not to use the parent worldspace LOD also got rid of the LOD object inside the city. Of course this means that the city now just floats in the skybox, but that's not a huge issue, since the walls are tall and you can't really see over them. Edit: Just checked the map and it looks like despite setting the AllHDLOD32 to 1 in the ini, the objects that previously had non-HD (bright) snow on them still do. I checked the mesh in nifskope and it looks like the names of the objects are changed to HD but the shader flags aren't. At least in the tests I conducted last time it looked like simply changing the names of the objects was not enough, the shader flags needed to be changed too to swap the snow to HD. I changed the shader flags on High Hrothgar to HD and then the snow matched the other HD snow as intended. One more odd thing I noticed is that when first going to an exterior the DynDOLOD Successfully Initialized notification isn't printed, no matter how long one waits. It's printed only after first making a save in an exterior and loading it. Don't know if this is indicative of a problem or anything, just different than what it used to be. I attached the Papyrus log here just in case: https://mega.nz/file/tTdFHKTD#909i7u0t8DLNl0Go0A4T-I6Ks8jGr19UOuqBuf9JL0U Another edit: Found one more problem when poking around Markarth testing things. There's this rectangular water object floating a bit above the normal water and clipping with things. The editor ID is skyrimesm_0F6F5F_Tamriel_DynDOLOD_OBJECT

I've been testing the new parent/child copy feature, and so far looking great, thank you so much for adding this in. There were a couple things I wanted to ask about though. In some places objects seem to be missing. The places I found where this is visible without console hacking are the Dragonborn Museum Safehouse balcony in Solitude and in front of the Honorhall Orphanage looking towards the Riften fishery in Riften. I assume this is because cells containing refs in the child world don't receive any refs from the parent world, or something along those lines? Another thing I noticed is that refs in the parent world that have had their base objects swapped with Base Object Swapper use their original base records in the child world. Here are two pictures from the Whiterun stables to demonstrate. The first one shows the fences as they appear in the parent world (Tamriel) having been swapped with BOS, the second shows them in the child world (WhiterunWorld) using the original base record. This is of course quite minor and barely noticeable, but just wanted to make sure whether it's because Base Object Swapper is not supported for this feature, or if there is a bug of some sort. Lastly, at least in MarkarthWorld there seem to be some issues with large references. The first picture is taken with uLargeRefLODGridSize=5, the second with uLargeRefLODGridSize=9. The bridge and some other large objects disappear when they enter the large ref grid. I have added the "Use LOD Data" flag to the Parent worldspace field of MarkarthWorld so that Markarth uses the Tamriel LOD instead of its own LOD. Here's a link to the logs: https://mega.nz/file/RWFHgJ4C#3_wi91qevRJLXpEbAIXO57E_XrgJsTemNRkq1jOFxOo Almost forgot, there were also these things: The first picture is from Evermore in Beyond Reach, the second is the entrance to Cidhna Mine in Markarth. To my eyes it looks like either LOD or the underside mesh, but I wasn't able to target it in console so I assume it's the former, unless things have changed. Edit: Remembered the tll command. Using it made the low res objects disappear, so they indeed are LOD.

I would like to know more about the new heighmap options added in the INI. I tried looking on the website and doing a search in this thread but couldn't find where they were explained. ; Set to 1 to create terrain heightmap textures DoTerrainHeightMap=0 Does the heightmap in this context mean the heightmap used by things like the parallax shader, or something else?

Could try generating terrain LOD with the LODGen textures from Cathedral Landscapes. https://www.nexusmods.com/skyrimspecialedition/mods/21954?tab=files

Sounds good, thank you.

I think the non HD is closer to the truth, but whether it's completely correct I'm not sure. Like mentioned earlier I'm using BDS 3.5 which has a slight blueish tint to the dynamic snow, but due to how different the lighting is on the map compared to the rest of the game I find it hard to say whether the blueish tint is present in the non HD snow or if it's completely white. Here's a comparison, with MM (white snow) on the left and BDS 3.5 (blueish tint) on the right: Thank you, I managed to finish the tests and here are the results. Before doing any changes: All objSnowHD renamed to objSnow: All objSnowHD renamed to objSnow and changing the HD_LOD_Objects flag to LOD_Objects: All objSnow renamed to objSnowHD: All objSnow renamed to objSnowHD and changing the LOD_Objects flags to HD_LOD_Objects: So in conclusion, changing the names alone seems to have no effect. Switching shader flags from HD to non HD breaks the snow, and only going from non HD to HD swaps the snow shader as intended. Personally, out of these options I would probably choose the last one.

I tried to do this in Nifskope, but it "sanitizes" names (forcibly changes the names of all the blocks that have the same name). Is there a way to stop it from doing it, or a better program for editing the .bto files?

Thank you. I tried fidling with the shader and INI settings, but couldn't find anything that made a difference. The terrain LOD is already generated with the CL LODGen snow textures and they were disabled when generating the DynDOLOD output. I think it might just be some quirk with how the map is rendered, after all there is no "HD Snow" in the vanilla map.

Alright, that explains why LOD16 works, because it doesn't have HD snow. There are still two things I don't understand though: First is that in my setup, SnowLODMaterial and SnowLODMaterialHD have identical colours. The second is that in LOD4 the HD snow has the expected colour. Really no idea what to do about this. I guess it could be some rendering thing specific to the map? I'll try asking on the Clear Map mod page in case anyone there has any ideas.