heheloveer

Got it. Thanks for the explanation!

Well, since there's already one mismatch caused by root node transformations I can imagine similar things exist in other models from the mod as well. But you're right, this should be analyzed case by case, and as long as I don't notice them causing any visual problems like the bridges do, I guess I don't need to mind them. Is the end result supposed to look like this? About dynamic lod, I'm actually quite confused: as I understand it every mesh mask rule includes settings for both the static and dynamic lod. So what dictates whether a lod is dynamic or static in game?

I haven't seen it in game yet since it's late where I am and that my game has been plagued with a strange CTD recently, but I can see how this could fix the issue after editing the mesh in NifSkope. This makes me wonder though, some other lod meshes in the mod also have translation in the BSFadeNode. Does this mean their in game positions would also be different from the full models'? This also reminded me, the LODGen log has this message: meshes\cotn\landscape\bridges\lod\cotn_wood_small_01_noroof_end_lod.nif unexpected root node. Ignoring file. Now that I thought about it, it's most likely related to what is described here. However I looked at the mesh and its root node block type is BSTriShape, and I can't seem to convert it into BSFadeNode using NifSkope. Any workarounds? Lastly I asked about how to show the Whiterun Temple Tree on the map. I use Level 32 object LOD for the map and changed the wrtempletree rule several times but could never get it to show. In fact sometimes the tree could also disappear from in game when viewed from a distance outside the city, which is very peculiar, since I even resorted to making all levels of its lod use the full model.

As with the last time, everything DynDOLOD related in the papyrus log seemed pretty normal. As for the Northern Roads problem, the misplaced model is indeed a lod mesh included in the mod, and since it's an object lod and not a full model, clicking on it with the console open would not produce any results. In case it's somehow useful, screenshots of the console displaying the information about the full model: Note that the two bridges use the same model and the lod of both these bridges are misplaced. The related meshes are attached here. Maybe you can see whether there are any problem with the meshes themselves. COTN_WR_Bridge_LOD.nif Papyrus.0.log COTN_WR_Bridge.nif

Reported this in version 118 and after updating to version 119 it seems the large reference bugs persist in the same cells. Maybe version 119 fixed such occurrences in some other cells, I'm not sure. Also I can confirm this does not only happen in Whiterun, but in Falkreath as well, so it's pretty widespread. Logs and the files you requested last time are here: https://anonfiles.com/88s8c5fbz8/Logs_and_Stuff_rar Also, two unrelated questions: 1) The mod Northern Roads replaced the Whiterun bridges with its own unique models. The bridges looked and worked completely fine but after generating lod with DynDOLOD I noticed the lod models of the bridges seem a little bit misplaced, as shown in the screenshots. What could have caused this and is there a fix? 2) How to make the Whiterun Temple Tree show up on the map? I use LOD Level 32 object lod for the map and tried editing the wrtempletree rule, but nothing seemed to work.

I haven't tried the new build myself but this is pretty much the effect I envisaged. Without backlighting the grass lod would not be lit up when in, well, backlighting conditions. This may or may not match the full grass very well since the way full grass reacts to backlighting conditions depends on complex grass normal map and ENB complex grass settings, among other things. I have already noticed in your screenshots the grass would be partially lit up even in backlighting conditions, so re-enabling backlighting but tune down the force seems to be the way to go, while I imagine I might as well ditch backlighting altogether since my grass doesn't really light up when the camera's facing the sun. Anyway I think each user have to observe how their full grass react to dawn/dusk sunlight and adjust the ini settings accordingly in order to have the best matching grass lods. It might take some work and experimentation, but now we do have the option to control it better.

I said LOD32 textures generated with xLODGen default settings can look dark on the map, not that they are not supposed to be like this. Some people may find them not to their taste (not me, I'm perfectly happy with those textures), so I said they could try to increase fSplitDistanceMult to, like you said, push LOD32 out beyond the max render distance so these textures are essentially only used on the map. As for the latter, it's not a question about generation, it's just about how that setting affects things in-game exactly. Nice to have some confirmation though.

Wow, that's a lot of yelling. Guess communication really is hard. In my experience LOD32 textures generated with xLODGen default settings can indeed look pretty dark on the map, but for all intent and purposes tampering with the brightness settings will likely result in some color mismatch somewhere. Of course you can just push fSplitDistanceMult all the way to the top so that you'll probably never going to see LOD32 terrain outside the map. Another way out is using paper map mods, but that's a different story. As for my own z-fighting problem, I tried several Optimize Unseen values but the flickering remained pretty obvious. Also on a closer look I'm pretty sure even some large reference full models and object lods near the water are affected as well. In the end I just decided to copy Step Guide's Optimize Unseen values and call it a day. I think with their settings the flickering was not as prominent, but I could be wrong. In any case I'm done with this. One last question for now: with the mesh quality of all levels of terrain lod set to 0, would there still be a visual/performance impact when I adjust the fSplitDistanceMult value? Aside from the texture size differences, I mean.

Me again. I noticed some pretty substantial flickering around the volcanic pond edges, as shown in here. Maybe this could happen around other water edges as well, but I didn't check. It's most definitely terrain lod related and has nothing to do with large references. I used 0 quality for all lod levels when running xLODGen. Optimize Unseen setting for LOD4/8/16/32 is Off(Protect Border)/On/On/550, as per the general recommendation. Also probably unrelated but I left the Max Vertices setting unchanged at 32767, but the logs are saying Max Vertices is at 30767. Is it supposed to be like this?

Thanks for the explanation! Guess I should check the Mods section of the website more often.

Glad to have helped! Erm, and I just thought of some other lod related things... I've been spending too much time on far away things and looked too closely at them recently. One of them is terrain lod related, I think, so I'll report it in the xLODGen thread. As for the other one, I use Skyrim 3D Windmill and after running DynDOLOD I found the LOD model still resembles the vanilla windmill. Is this expected behavior? The mod doesn't come with any lod assets.

If you're asking for DynDOLOD_SSE_log.txt and DynDOLOD_SSE_Debug_log.txt, I'm testing with the same DynDOLOD output (with modified complex grass billboard) with which I tested complex grass lods earlier, so they are still here:https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip The other four files you requested is attached here. Log and stuff.zip

You're right, I checked affected cells more closely and indeed other object lods are also loading when they really shouldn't. It's just not as obvious. Anyway one such affected cell is Cell -3, -4, Block -1, -1, SubBlock -1, -1. Also after moving the player character there, I noticed some cells that newly enters the uLargeRefLODGridSize zone began to be affected by large reference bug as well.

I made a save on the Whiterun watchtower and every time I load the save the grass lod bug appears, even if when I made the save the grass looked completely normal. As I suspected this only happened in large reference cells outside the loaded zone, since changing uLargeRefLODGridSize to 5 apparently fix this. Moving the player character to the previously affected area also makes the lod grass go away. Notice in the screenshots how not all cells are affected by this. I can't seem to find any particular pattern in affected cells either. The second screenshot shows how it looks like up close. I enabled papyrus logging and there doesn't seem to be anything related to SHESON_DynDOLOD scripts in Papyrus.0.log. Should I disable large reference bugs workarounds and regenerate DynDOLOD to see what happens? Papyrus.0.log

Culprit was just a figure of speech, I’ll take weirdly bright LOD grass for like half an hour during sunrise and sunset over non-EVLAS lighting any day. Also it makes sense that normal maps made with different values would affect how the complex grass reacts to sunlight. Guess there might be some need for controllable backlighting strength after all…

1) Of course this isn’t related to complex grass, just something I noticed when testing grass lods. Anyway I use A Clear Map of Skyrim and Other Worlds. I’m pretty sure there is an ini file in that mod that enables the LOD32 map settings. In my knowledge the related bug is most commonly caused by installing that mod (thus enabling LOD32 map settings) while not generating needed LOD meshes with DynDOLOD 3? It can cause quite a mess, with LOD models appearing in loaded cells, but I don’t think these abnormal grass lods I saw appeared in loaded cells. Aside from them I only noticed some occasional faraway flickering likely caused by some large reference bugs. Nothing suspicious in loaded cells. I’ll get around with further testing sometime later. 2) Sure, I know it would likely be too much of a hassle for you to account for all these mods. In any case this can be easily fixed by users.

Glad to see you already have some potential changes in mind. I think I should mention two other smaller problems I've encountered before you make an update: 1) When I was testing grass lods I noticed sometimes when I fast travel to Whiterun watchtower or load a save there, the grass lods would appear in some cells that should be inhabited by full grass. More specifically, I use grass lod mode 2 so the grass lods should only exist outside the uLargeRefLODGridSize area, but for some reason they can also appear inside it. This doesn't happen for all the cells in the area, only some of them, and I'm pretty sure the actually loaded cells weren't affected. In the affected cells grass lods coexist with the full grass that should be there. If not for the obvious color mismatches that we've been discussing I probably wouldn't have noticed them. Using LOD Unloading Bug Fix fixes this temporarily. 2) The Whiterun Exterior Patch in DynDOLOD Resources may conflict with mods that replaces the two bridges near Whiterun, like Lux Via and Northern Roads. After running DynDOLOD, lod meshes that match these mods' models would appear outside the city, but since the Whiterun Exterior Patch places full model vanilla bridges in the same places, there would be an overlap of bridges. This could be easily solved by removing some lines in the patch file or removing the added bridges in the DynDOLOD plugin though. Do you think you should include some kind of patch to this or that the patches should be provided by the mods' authors? In case logs are needed, just use the ones I included with my previous post: https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

I just spent a lot of time testing and the results are very very interesting. Not many screenshots though since I tested way too many things to record down one by one, and you'll have to trust my words for it. In any case, a key culprit for the phenomenon I encountered (LOD grass lighting up at dawn/dusk when facing the sun while full grass doesn't) was EVLAS. I also believe EVLAS is also responsible for the phenomenon shown in z929669's screenshots. The summary to my findings is, EVLAS makes grass lods react to dawn/dusk lighting much more aggressively, as in, they can become very, very bright. With my ENB preset it isn't much of a problem when facing the direction opposite to the sun, since the full grass is also lit up, but when you're facing the sun, the effect becomes quite jarring, especially when EVLAS makes terrain and full grass turn darker. The screenshots were all taken with grass lods generated with the default billboard (with Back_Lighting flag). Without EVLAS, grass lods with or without Back_Lighting work more or less fine to me, but with EVLAS it seems Back_Lighting has to be removed so that grass lods won't become an eyesore when facing the sun, at least in my case. The other interesting problem is the one illustrated in z929669's screenshots. We weren't really describing the same phenomenon, since in his screenshots the camera was facing the sun but the full grass was also quite bright, at least when the sun hadn't been obstructed by the mountains. He noticed that when the sun was obstructed but not yet sunk below the horizon, the full grass became dark but the grass lods remained bright, and I think this is also a behavior brought about by EVLAS. Step Guide does include EVLAS so I'm assuming he was using it. Anyway, without EVLAS, both the full grass and the grass lods would, as he described, "stay lit up until most of the ambient sunlight is gone". With EVLAS, sunlight can be obstructed by terrain and objects, and the full grass would not light up when the mountains are casting shadows on them. But grass lods behave the same as before: they begin to gradually light up when it's sunrise time, regardless of whether there's actually sunlight present. With Skyrim as mountainous as it is, this could create some quite confusing visuals when the sun is over the horizon but not over the mountains. Removing Back_Lighting flag doesn't really help in this case, since the grass lods would still light up when they think "it's time", albeit only on one side, instead of on all sides. z929669 thought it's likely an engine limitation and I'm inclined to agree. In any case this is for sure far beyond me to find some sort of fix. Another thing I noticed is that, as I mentioned, in z929669's screenshots the full grass were bright when the camera was facing the sun, but in my game it would only light up when the camera is facing the opposite direction. I'm not very sure what makes the our games behave this differently. I found increasing SubSurfaceScatteringAmount parameter in ENB complex grass settings could make the grass somewhat brighter in backlighting conditions, but in the ENB preset he used this value isn't very high. This is worth considering however. If I understand it correctly, in some setups the full grass are darker when the camera's facing the sun, while in others they are brighter. This would mean some people have to resolve this "overly bright grass lods when facing the sun" issue while others don't, since the full grass are also bright anyway. Anyway here's the logs and the ENB setting I used. I ran DynDOLOD two times with the same setting and TexGen textures. Only the billboard meshes were changed. https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

Yes, so I'm doing what I can by reporting this potential problem and a potential solution that I have. Also you reminded me that I could support you monetarily. I will consider this when it's not 1 AM where I am lol. I understand default settings are for the vanilla game, users have to make adjustments to make it suit their game better; what I'm trying to say is that editing meshes isn't the same as changing a setting, either in the UI or in the ini files. If, I mean if we can establish that billboard without Back_Lighting flag is in some scenarios preferred, I would suggest including one such mesh in the files, make it billboard 3 or something so that users could switch to it just by editing the ini file, not the mesh itself. Anyway this discussion has all been rhetorics and I don't have anything else useful to say right now. I'll be back with the information I promised.

Grass mod is QW's Grass Patch (main version) with complex grass textures from https://www.nexusmods.com/skyrimspecialedition/mods/67304. ENB preset is Rudy Cathedral Zangdar's version. I meticulously followed the installation guides provided by their authors and have installed all their prerequisites. I mean, DynDOLOD should support all kinds of modded content, right? Maybe it's just because I messed up somewhere but the grass mods I use are popular. If what I saw in my game can be replicated, it would mean lots of other people might be experiencing the same problem, and they deserve a more... well, officially supported way to solve this. Editing the ini files? Sure. But I don't think users should resort to editing the mesh themselves, or at least, there should be some mention in the official documents that editing the meshes are in some cases necessary. I will provide the logs, screenshots and any other relevant information I can think of sometime later and you could decide what to do with them.

I already said I use Qw's Grass Patch (and of course all the grass mods it combines), Rudy Cathedral Zangdar version and latest ENB binary. The logs and ENB complex grass settings would have to wait but I don't think I edited the complex grass parameters from Rudy's preset. Also I'm pretty sure DynDOLOD behaved the way it should and it's only a model problem, but if you insist I could run with both versions of the billboard model and provide the respective logs.

I'm sure I have complex grass effect enabled in ENB, have installed complex grass textures and have used DynDOLOD_flat_4x2alt_lod.nif as grass billboard, though it will have to wait for some time before I can produce some before/after screenshots to prove my claim. Do you plan to verify this yourself at some point? Edit: I see you uploaded a video and if that's a full day-night cycle the vanilla grass lod does seem to behave normally. Indeed, it probably have something to do with the grass mod I'm using. Would you look further into this problem? Many people use modded grass so I think they could use some official support regarding this matter.

I'm not sure if this is the right place to ask this, but why does the complex grass billboard (that is, the DynDOLOD_flat_4x2alt_lod.nif file) need to have a Back_Lighting flag? I noticed in my Skyrim the color seam between full grass and grass lods wasn't too prominent during daytime and nighttime, but when it's dawn or dusk some parts of the grass lods lit up like crazy while the full grass nearby are all dark. I later found out it's because both sides of the grass lods lit up when the sunlight was coming from one side. If you look towards the direction the sun is facing, full grass and grass lods would all light up and color seam would be minimal, but when you look towards the sun only the grass lods would light up. This resulted in a massive color difference and the effect in itself was also quite jarring to see. I experimented a little with DynDOLOD_flat_4x2alt_lod.nif and found out removing the Back_Lighting flag from the mesh makes complex grass lods generated with it react to sunlight normally. I'm not a Nifskope expert and there's always a possibility that only I encountered this strange phenomenon, so I came here to ask. FYI, I use Qw's Grass Patch (and its complex grass retexture, of course), Rudy Cathedral Zangdar ENB preset and EVLAS. Both DynDOLOD and ENB are at their latest versions.

With this version the grass lods are indeed found in the meshes and the file size is more or less the same with my previous working output. I didn't enable verbose this time so the logs don't contain much information, but I imagine it's working alright. Thanks for the help! Edit: just enabled verbose and generated a single LOD4 area. Sure enough there isn't any "grass mapping not found" message in the logs.

I just reran TexGen and DynDOLOD with as far as I know the same results. Here's the link to the logs: https://anonfiles.com/o8D3u2Z5y1/DynDOLOD_logs_zip The DynDOLOD debug log was extremely large but there was no fatal errors nor did the program produce a bugreport.txt.