Mousetick

I tested Alpha 140 with the updated USSEP rules: SUCCESS. Thank you much. Some bad screenshots for a problem report, but good enough for a success report: Tamriel LODs > Before fix > After fix I had rushed to thinking this was related to Parent > Child but now realize this has nothing to do with it. The problem would be same with it disabled. Which got me thinking further. As the goal of the Parent > Child feature is to make the city exteriors consistent between parent and child, as well as make the child references consistent with the parent object LODs, it might be helpful to issue a log warning when a perfect parent/child match within a single plugin (i.e. the "ignore master" case) is broken by another plugin overriding it. For example, another plugin might move, resize or disable either parent or child reference, which would produce bad and unexpected results for the Parent > Child feature. Such a warning would help identify the cause of the discrepancy. Thanks.

The mod description is pretty clear about how it all works:

Hi sheson, It looks like you uploaded DynDOLOD 3 Alpha 140 to the DynDOLOD SE 3 Resources mod on Nexus: https://www.nexusmods.com/skyrimspecialedition/mods/52897?tab=files It's been a long day, time to take a break

I'll give you a proper report with screenshots, console info, logs etc. but it's going to take a long while. I'd need to update to Alpha 139 first, I guess. Meanwhile, please read my description in plain English which should be pretty clear without looking at pictures: Tree ref added by USSEP in Tamriel: [REFR:05063113] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26)) Copy of previous tree ref, in SolitudeWorld, also added by USSEP: [REFR:0506313A] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26) Relevant excerpts of debug log: [01:49] [DynDOLODGenerate] <Debug: 101 unofficial skyrim special edition patch.esp;0006313A None None None None None Delete Unofficial Skyrim Special Edition Patch.esp [REFR:0506313A] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26)> [...] [04:55] [ApplyReferenceRules] <Debug: Processing Unofficial Skyrim Special Edition Patch.esp [REFR:0506313A] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26)> [04:55] [DisableReference] <Notice: Disabled Unofficial Skyrim Special Edition Patch.esp [REFR:0506313A] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26)> [04:55] [CopyMainRecordToFile] <Debug: Processing DynDOLOD.esm Unofficial Skyrim Special Edition Patch.esp [REFR:0506313A] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Persistent Children of [CELL:00037EE6] (in SolitudeWorld "Solitude" [WRLD:00037EDF]) at -17,26)> [...] [16:13] [AddMissingReferences] <Debug: Ignoring master Unofficial Skyrim Special Edition Patch.esp [REFR:05063113] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))> Commentary: At 1:49, DynDOLOD acknowledges the Delete rule from DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini concerning [REFR:0506313A]. At 4:55, DynDOLOD applies that rule by disabling [REFR:0506313A] in DynDOLOD.esm. After that point, [REFR:0506313A] no longer "exist" in SolitudeWorld, it's not visible anymore. [REFR:05063113] in Tamriel has become "orphaned": it no longer has a matching copy in SolitudeWorld, since [REFR:0506313A] has been permanently disabled. At 16:13, DynDOLOD decides to "Ignore master" for [REFR:05063113] because it apparently doesn't see that its copy [REFR:0506313A] has been previously disabled by DynDOLOD.esm. That evaluation is incorrect, as there is effectively no visible copy for [REFR:05063113] in SolitudeWorld anymore. Repeat each step above for each and every tree reference added by USSEP in Tamriel, with its corresponding copy in SolitudeWorld disabled by DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. End result: USSEP tree references in the cells outside the walls of Solitude have Tamriel LODs (as expected). Inside SolitudeWorld, when those LODs fade, no full models appear for those trees, since their copy was disabled and no new copy was made by DynDOLOD during Parent > Child. Full logs (using Alpha 134) here if you'd like to take a look: https://drive.google.com/file/d/19EQbVwyzUSpR3ReaOWITDJFmMuKv5JYF/view Thanks.

Yes. Ok got it, thanks. Yes, but these references added by USSEP in SolitudeWorld are disabled by [..]\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. So their LOD fades to nothing. Are we supposed to manually delete or edit DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini to get the correct results? It seems counter-intuitive and not very user-friendly. It seems the issue is that Parent > Child tries to match parent/child references before rules are applied. How about making the Delete rules into a .patch instead, that would be applied before Parent > Child and Child > Parent are processed?

Skyrim SE, DynDOLOD 3a134 Hello, I'm the crazy guy who is obsessed with trees (or lack thereof) outside the walls of Solitude in SolitudeWorld not matching the Tamriel ultra tree LODs, and who made a big fuss about them in the past. I'm very grateful for the Parent > Child feature - this is a dream come true, so thank you very much. I'm also grateful for moving the vanilla occlusion planes further away so that more stuff is visible outside the walls in the child worldspaces. This is beautiful. I'm trying to understand why some references are not being copied to child worldspace when Parent > Child is used. Specifically, some USSEP tree references are not copied to SolitudeWorld, even though object LOD is generated for them in Tamriel worldspace. Relevant DynDOLOD_SSE_Debug_log.txt log lines for [REFR:05063113]: [07:39] [BuildReferences] <Debug: Meshes\landscape\trees\treepineforestsnow03.nif_-670_1074_-52_105 Unofficial Skyrim Special Edition Patch.esp [REFR:05063113] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))> [...] [08:19] [ApplyReferenceUpdates] <Debug: Processing Default Unofficial Skyrim Special Edition Patch.esp [REFR:05063113] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))> [...] [16:13] [AddMissingReferences] <Debug: Ignoring master Unofficial Skyrim Special Edition Patch.esp [REFR:05063113] (places TreePineForestSnow03 [TREE:0005C070] in GRUP Cell Temporary Children of [CELL:0000925A] (in Tamriel "Skyrim" [WRLD:0000003C] at -17,26))> What causes the Ignoring master message above? I couldn't find anything in [..]\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_* config files that would cause this. These references do not appear in DynDOLOD_SSE_ChildworldMatches.txt so there is another reason for them to be skipped. Trees added by USSEP in [CELL:0000925A]: Trees copied by DynDOLOD to DynDOLOD.esm in [CELL:0004E3DC] (they're all from Skyrim.esm): Is there a separate log for Parent > Child copies? It looks like [..]\DynDOLOD\Logs\DynDOLOD_SSE_ChildworldCopies_Tamriel.txt is only for Child > Parent copies. Thank you.

This note on the wiki/guide no longer applies with the 'Basic' option, it should be removed: Furthermore, unhiding the 'Basic' plugin wouldn't have the effect described in the note. As was discussed in earlier posts with @CorneliusC, the 'Basic' plugin is a trimmed down version of the 'Extended' plugin(s). It doesn't add any features, it only changes game settings. It should still be hidden, but for different reasons than those given in the note.

I already chimed in a while back, but that apparently went under the radar. You'll be happily surprised that that most likely won't be needed, unless you pick a fancy animation or physics mod that goes way out of the STEP mandate.

Example showing the positive effects of Optimize Unseen = x in a scenario it was intended for. LOD 32 Tamriel -64,0 (area covered is 32x32 cells) Quality 0, Optimize Unseen = 550, Protect Borders (STEP LOD 32 settings) With water > Without water > Wireframe At Quality 0 for such a large area, there is no way the resulting mesh could have used fewer than 32K vertices, so the mesh generator had to combine triangles to stay under the limit. The generated mesh has 61837 triangles and 31374 vertices, which is roughly the maximum possible. It means the maximum was exceeded and then triangles had to be optimized away. Areas of interest (click to zoom): The blue rectangle shows the effect of Optimize Unseen being enabled. The triangles covering the seafloor are a lot "coarser" than the above water terrain, and the underwater terrain has essentially been flattened. Much fewer triangles used for underwater means more triangles available for above water terrain. The orange rectangles show the effect of Optimize Unseen = 550 along the shorelines: Notice how the shoreline sharply drops in height and how it is more detailed than the surrounding terrain, while its contour, made up of relatively long straight lines, is not smooth. Beside preventing z-fighting, this transformation is better than what the mesh generator would have done without, it makes the shorelines more clearly defined on the map.

The interface and scripts folder are not used when the 'Racemenu + XPMS MCM' plugin is hidden. Only the meshes folder is used. This was discussed a long time ago in this or another topic when it was decided the plugin should be hidden. The FOMOD option that is functionally identical to current STEP installation, minus all the crap that was installed but not used, is the 'Basic' option, i.e. only meshes folder (containing skeletons and animations). Why force users to go through a byzantine array of FOMOD options to install stuff that is not used? Nothing will be missed by selecting 'Basic'. Make it simple for users to install and for you to support. If users need extra features beyond 'Basic', they can always reinstall the mod and figure out which Extended options they need.

I found one helpful clarification from the MA about the FOMOD options on this mod's recent comments, among the ocean of confusing and approximative answers:

That was a rhetorical question I've reworded my post to remove the ambiguity.

One last remark and then I'll finally shut up The 32K limit notwithstanding, LOD 4 is a special case in regards to optimize unseen because the game constantly switches between LOD 4 and full landscape as the player moves and LOD 4 is closest to the player. The LOD 4 shoreline needs to be as "pristine" as possible to ensure smooth seamless back and forth LOD 4 > full landscape > LOD 4 transitions. The "deformation" produced by optimize unseen = x is therefore undesirable. Moreover, depending on water opacity/murkiness and lighting, the holes created by optimize unseen = 550 at LOD 4 (see screenshots) might be noticeable by a player diving underwater and looking in the distance.

To put things into perspective re: performance concerns due to increase in triangles with optimize unseen off. I caught this bit from the latest Embers XD 2.8.7 changelog: 23K triangles for a bunch of small rocks. 'Nuff said. sheson gave a great explanation about optimize unseen. It's really "clicked" in my mind only now, but the way I understand it, optimize unseen is first and foremost a quality improvement, and the (marginal) performance improvement resulting from fewer underwater triangles is an incidental side-effect. The following is merely paraphrasing that explanation, but focusing on LOD level > 4. At each subsequent LOD level above 4, the area covered by the mesh is 4 times that of the previous level, so at constant quality, the mesh theoretically uses 4 times as many triangles as the previous (or practically the sum of the 4 lower level meshes making up the new level mesh). LOD 32 is 4x LOD 16 is 4x LOD 8 is 4x LOD 4. The 32K vertices limit per mesh is the same at any level however. When the limit is exceeded the terrain mesh generator starts combining triangles to reduce the number of triangles/vertices. It does this equally to triangles above or under water. Since the underwater terrain is not visible, even more so at higher LOD levels, it makes sense to combine those triangles first (degrading the quality of the underwater terrain in the process) to free up more triangles to use for the above water terrain, which needs to have the highest quality and number of triangles as possible. That's what optimize unseen does. Optimize unseen ON (which is equivalent to optimize unseen 0) can cause z-fighting with shallow underwater terrain and higher LOD levels, so it may be necessary to shift the combined underwater triangles deeper, using optimize unseen = x. Optimize unseen = x causes the shoreline to become "sharper", due the way the triangles shifted deeper under water, and the triangles above water, are connected. This is a desirable effect at higher LOD levels, particularly on the map (LOD 32). Optimize unseen is "useless" for LOD 4 as its primary function is not required: the 32K vertices limit is never reached. It can be worse than useless: see screenshots above. If performance is an issue at LOD 4, I'd suggest the quality setting should be adjusted to lower the number of triangles across the board whatever the terrain type, rather than relying on optimize unseen.

Looks like you encountered a bug that was just recently fixed in Alpha 137. Install Alpha 137 and try again. DynDOLOD is trying to copy a CELL record from TSR_TeldrynSerious.esp into DynDOLOD.esm, but TSR_TeldrynSerious.esp can't be a master of DynDOLOD.esm because it's lower than it in the load order (or in other words, DynDOLOD.esm is "too high" relative to TSR_TeldrynSerious.esp). https://dyndolod.info/Changelog:

Before/After data points for Terrain LOD settings change: Optimize Unseen 500 changed to Optimize Unseen OFF for LOD 4 Normal Mipmaps turned off for LOD 4 Diffuse and Normal Mipmaps turned off for LOD 32 Before After +/- Tamriel generation time* 12 min. 8 min. -33% Tamriel meshes total size 216 MB 273 MB +26% Tamriel textures total size 582 MB 476 MB -18% [*] Generation time to be taken with a grain of salt due to light multitasking and operating conditions not identical between before and after. The mesh measurements can't be extended to random load orders, as they depend on the landscape of worldspaces. For example, my load order contains 55 worldspaces: *** My specific load order *** Before After +/- Terrain LOD meshes total size 855 MB 970 MB +13% Terrain LOD textures total size 6.29 GB 5.14 GB -18%

If you already haven't done so, download and install 'Skyrim Special Edition GOG and Epic Games Support - Mod Organizer 2.4.x' from the update files section of Mod Organizer 2 on Nexus. The GOG version of Skyrim SE uses %LOCALAPPDATA%\Skyrim Special Edition GOG instead of %LOCALAPPDATA%\Skyrim Special Edition. MO2 doesn't handle this GOG-specific location unless the aforementioned update is installed. The STEP SSE Guide is designed to work "out of the box" with the Steam edition of Skyrim SE/AE. Any other "platform" is not officially supported. You'll need to configure various tools used by the guide, starting with MO2, specifically to account for the non-standard folder locations used by the GOG edition of the game, otherwise these tools won't work as expected or at all. Consult each tool documentation and/or search online for guidance. They all work fine with the GOG edition but they require the proper settings, to be manually configured.

My off the cuff take on this is that at a slightly lower quality, pretty much indistinguishable to the naked eye from quality 1, the number of vertices is already pretty low and doesn't need to be optimized. ~10,000 or less vertices per quad is peanuts. The shoreline and marsh with Optimize Unseen 550 look awful. I've regenerated all my terrain LOD with quality 2 and optimize unseen off. We'll see how it goes. I won't be posting screenshots or comparisons however.

I couldn't find the answer in Terrain-LOD-Readme.txt or on https://dyndolod.info/Help/xLODGen so asking here. Hopefully it's not a FAQ. xLODGen mesh generation log line: Finished LOD level Tamriel.4.-28.80.btr [7733/32] The first number in [brackets] is the number of triangles generated, but what is the second number? It's always an even number. Thanks.

Comparison of different Quality settings All sequences are Quality 1 > Quality 3 > Quality 5 Optimize Unseen OFF Optimize Unseen ON Optimize Unseen 550

I didn't want to "spam" this topic so I made a separate topic, but this may be of interest to this topic's readers:

Using xLODGen beta 99. Tamriel -20,20 quad was selected for its good mix of hilly terrain, river coast, small islands and marsh. All meshes were generated at Quality 1 (default). Variations: Optimize Unseen OFF, ON, 50, 550, 700. Protect Borders option enabled. I tried to use a view perspective in NifSkope that shows the marsh, riverbed and river shore as much as possible, but rather than a top-down view, something closer to an in-game perspective. Solitude Stables are on the North side, Solitude Docks are in the North-East corner. All sequences are OFF > ON > 50 > 550 > 700. The title in the top left corner of each picture shows which variant is shown. View with water without wireframe View with water with wireframe View without water without wireframe View without water with wireframe

I think I get what you're saying: make the diffuse solid and the normal flat, but make the normal mipmaps bumped. If the texture is bumped at a distance, the normal mipmap is used.

But we already know, at least going by what sheson tells us, that the game uses diffuse mipmaps at LOD Level 4. That is not disputed. The guide enables this option, so it's all good. The question is about normal mipmaps, which are not used by the game at LOD Level 4, but are enabled by the guide. There's also the question of mipmaps at LOD Level 32, which are enabled by the guide, but are not used by the game (again, according to sheson). This is less of an issue since there are only a few textures, but they're pretty large. Please correct me if I'm mistaken: using different colors at different mipmap levels would be done in the diffuse mipmaps, it wouldn't make sense to have multicolored normal mipmaps. Then such a test would be useless to determine if the game uses normal mipmaps or not for LOD 4.

This couldn't be automated/scripted. The script wouldn't know which ones you want to keep/enable based on your personal taste. It's all or nothing based on objective criteria. I'd tackle this manually like this: Create an empty plugin. This is going to be a patch for the mod. Sort the patch after the mod. Load both the mod plugin and the patch in xEdit. For each disabled tree that you want to keep: Copy as Override... from Skyrim.esm (NOT from the mod plugin), or whichever is the last vanilla plugin, into the patch. Drag the scale and any other change you like from the mod plugin to the patch. This should be faster than un-disabling the trees one by one. Also it's better to put manual edits into a separate patch than editing the mod plugin directly. In case the mod is updated or reinstalled, nothing is lost. * The Copy as Override can be done in small batches, rather than one by one, by selecting multiple records first (shift-click or ctrl-click).