erehwonz24

Ah, that makes sense! Thanks. I'm actually not bothered by it now that I know why it works how it does--I figured I'd done something incorrectly. Good to know and thanks for the explanation.

So, I'm back. Everything is working quite nicely with one exception, and I've toyed with it but don't seem to be making progress fixing it. I'm encountering an issue with Knights of the Garter, and I'm just wondering if there's any precedent or existing info for working with that mod when using DynDOLOD. (Searching didn't turn up anything.) When I generate LOD, the castle for KotG doesn't show up from a distance (say, from Whiterun). I checked the logs and don't see any errors, only the "disabled NeverFade, replaced by dynamic LOD" message for most of the KotG files. Only other relevant mods making changes to that area, as far as I can tell, are Enhanced Landscapes and Enhanced Vanilla Trees. Looks like the castle doesn't show up regardless of where the KotG.esp is placed in load order. Anyone have any advice?

I just want to say a big thank you, Sheson. Your directions for renumbering worked perfectly, and my trees are finally behaving like proper trees. I have to admit that I resisted DynDOLOD for a long time simply because I run Skyrim with low quality LOD and didn't think I could afford an upgrade, but my LOD looks better than I ever expected at no cost in FPS. I'm delighted. Thank you for your help.

Thanks again, Sheson. I don't know how you keep up helping everyone all the time like you do, and it's appreciated! Final question and I think I'll be set--I discovered that, contrary to what I thought, most of the trees when using either Whiterun forest overhaul continue to have stuck LODs when combined with any other tree overhaul--Enhanced Landscapes, Enhanced Vanilla Trees, Skysight, etc. I think Zilav recommended renumbering form IDs, which I see referred to vaguely in the TES5Edit documentation--do you know of any decent resource for renumbering? Did a bit of Googling and mostly I only turn up directions for merging mods. Thanks again, seriously.

Thanks, Sheson! Really helpful. I'll give that a try soon--I'm away from my computer so I can't check right now. But when you say to walk up to the tree, should I TCL to it from the Tamriel worldspace? I've walked up to it from inside Windhelm and the 3D mesh never actually shows up. Otherwise, that makes sense. I'm not sure why the whole exterior of Windhelm stays LOD until I get within a few feet of it, though--but as long as I've played Skyrim with mods, Windhelm has been an ongoing issue. Could the persistent LOD wall section be a different issue from the slow-to-pop-in Windhelm meshes?

Thanks, both Sheson and Zilav, for your responses. I seem to have gotten the tundra trees working, and they look great. In fact, LOD in general looks great, and walking around Skyrim is more astonishing that I imagined it could be. Thanks for DynDOLOD. There's only one issue (maybe two) that I've run into. Now, if I am reading you correctly, this picture is an example of the child/parent world issue that you described. You said that "The workaround is to give those trees enable parents, with mesh rules for example, or give them to static LOD with setting their references to "Billboard" in LOD4/8/16." I think I follow this, but is there a tutorial or reference that would help me through the process? I'm happy to learn. This tree is just inside Windhelm. When I approach Windhelm in game, the LOD lingers far too long--I can still see LOD of its facade when I'm standing on the bridge directly in front of the gates, but it eventually does go away if I get really, really close to it. But one section of wall directly on the other side of that stuck LOD tree but in the Tamriel worldspace stays stuck. Any advice on how to troubleshoot it? I'm only running one mod that changes Windhelm, Snow City, and I've never had issues with it before. Thanks again.

Hi Sheson, Thanks for your reply. The first point makes sense, although the trees I'm finding are as far away from Whiterun as Rorikstead. To the second point, the log file gives me this message about the Tamriel worldspace: So that fits with what you've described. I have also had issues with LOD trees disappearing as I get near to them, although that doesn't seem to be happening anymore. The thing is, even when wiping out LOD and generating it new, and not moving load order at all, I'm still getting these occurrences. If I'm understanding you rightly, the stuck LOD may happen when there are duplicates and load order changes? Also, browsing the Great Forest page, I see that the author states this: That said, the author suggests that LOD issues have been addressed, and I'd think that more people would report the issue if it still were one. So I guess I'm back to something amiss on my end. Thanks for your time. I appreciate you dealing with my novice confusion. :)

Hello! A poster over at /r/skyrimmods suggested I post here about an issue I'm having with stuck tree LODs. Forgive me if this has been addressed in places where I didn't see it--I did search through posts in this thread and tried to follow through on advice given in a number of relevant posts, but I'm still having this issue. Basically, the stuck LODs only seem to affect trees in Whiterun Hold, which is heavily edited by the Great Forest mod. On a causal walk through the area, I counted at least thirty such LODs clipping through tree meshes that otherwise have loaded correctly. I tried wiping all LOD generation data and redoing them using both TES5LODGen and DynDOLOD, but the problem seems to persist. I have also tried different combinations in terms of load order (I'm running Enhanced Landscapes with Great Forest). I'm probably on my tenth time re-generating LOD and I figured it was time to ask. That said, which LODs stick seems to change each time I generate LOD, even if I change no settings in DynDOLOD and make no changes to load order. I know I'm doing something wrong, but I'm not sure where to begin. Despite a long time modding, DynDOLOD is new territory for me! Any advice happily welcome.