S-Matrix

Sorry if I'm being obtuse, but just in case, I want to point out that the following is also written in the section where the rule of thumb is detailed: "Vice versa, do not check this option in case the large referene system is used - uLargeRefLODGridSize > uGridsToLoad >= 5" I've actually spent a fair bit of today doing general performance tuning that extends beyond tweaking DynDOLOD, so I'd need to do more controlled testing to know anything conclusively. That being said, after finishing up the DynDOLOD gen process earlier with the box left unticked, my exterior performance in the Rift had pretty noticeably improved during the play session I started up immediately afterwards (in regards to both average FPS, and smoothness/consistency over fast camera rotations). I personally didn't notice any change in visuals whatsoever (just eyeballing, so of course this also isn't conclusive) - I have my Large Ref grids setting at 9, and as you probably figured, I'm using the Large Reference workarounds implemented via the NG DLL. Again, it could definitely just be that it coincided with unrelated and more significant changes I'd made outside of DynDOLOD (at the moment I don't remember what else I might have changed specifically before that session), so this is really just me saying that my findings, as of now, aren't exactly reliable and that I'd need a fair bit of time to set up a good testing environment (regenerating LOD, running a test save, etc).

Hi! I typically use the current STEP Guide iteration as a baseline for everything pertaining to LODs, and I had a question regarding the optional DynDOLOD toggle "Upgrade NearGrid Large References to FarGrid". The DynDOLOD site (on this page: Advanced Mode | DynDOLOD) explains that, if the large reference system is being used, the rule of thumb is to leave this unchecked. However, STEP Guide 2.3 instructions involve setting the large reference grids to 9 in the BethINI section but also ticks this box in both of the DynDOLOD config instructional images. I know it's possible that one source might be less up to date than the other and as a result may not reflect the most current technical details of DynDOLOD; additionally, the principle is theoretically just a rule of thumb as opposed to a strict necessity. If it's the latter case though, what makes it a good idea to do this for the STEP Guide load order as opposed to following the rule of thumb?

Yup, same error. Let me know if there's anything else I can try on my end at the moment.

New error with test version exe, with different error line: [Main Instruction] Error: No VMAD for SkyrimSE.exe DynDOLOD_FirstbornActivator "ThouShaltBowToMaster" [ACTI:00000902] Debug log: https://ufile.io/o1bvpfim DynDOLOD_SSE_log.txt

Hi! Getting an error running DynDOLOD for alpha-183; attaching logs along with line describing error details: Error: Access violation at address 00000000011AD0A9 in module 'DynDOLODx64.exe' (offset CED0A9). Read of address 0000000000000000. Also, in trying to attach the debug log directly, I realized the text file is 144MB in size - would that indicate something like a system problem right off the bat? Let me know if there's a preferred place to host the large text file, as for now I'm using a file.io/limewire link. I'm gonna give it another run in the meantime and see if the exact error is repeatable. bugreport.txt DynDOLOD_SSE_log.txt

Using xEdit 4.04, I believe - I saw today that there's an update available, so it's probably a good idea to move to the newest version. Gonna be afk for an hour or two, so I'll post with news later in the day.

Here it is: https://imgur.com/a/7Df35ed Not sure if it's normal for there to be two instances of it appearing in the asset window search results, but the assets listed for both entries are the exact same.

That's correct. Here's the list of textures you asked for: https://imgur.com/a/aK9UYFE As you can probably see, we have a lot of conflicts; however, these conflicts are all (I hovered over each one to be sure) between Mrf's Solitude and Kartoffel's Cleaned Textures. This specific conflict is completely expected, as Kartoffel's mod covers every texture in the game and I'm using it as a base. The one exception to this, as you also probably noticed, is in the case of swindow01_g.dds (which I assume is a glowmap or something similar). TexGen Output takes precedence here, but that texture is also found in USSEP, the lighting mod "Lux", and then again in Mrf's Solitude. My amateur's hunch is that this may be significant, given that Wizkid's mod for ENB window glow was also implicated in the crashlogs I'd posted. Keep me posted with new things to look at and report back with.

Voila, that's fixed it! Thanks so much Sheson, and let me know if you need anything else from my end to figure out the root cause of this, or if there's anything else I need to do as far as generation is concerned now that the ESM is edited.

https://imgur.com/a/xNfWHAC Let me know if this is everything as you wanted it/if you need anything else at the moment, and I appreciate you sticking with this.

Hi sheson, thanks for the reply - as per your suggestion I checked to make sure the mesh would open properly in NifSkope, and it did indeed do so. Next, using MO2's "Data" tab, I was able to see each mod in my load order that was contributing a version of the mesh; the one provided by "Flickering Meshes Fix" was the overriding version, so I isolated and then deactivated that file from the mod, and returned to the problem area, but the issue persisted. Before trying CAO, I decided to try removing the version of the mesh provided by "Assorted Mesh Fixes", which was next in line in terms of override/use by the game, but the crash still occurred. I repeated the process one last time with the "Landscape and Water Fixes" version of the mesh, mostly as a sanity check - alas: crash. Honestly, I'm not the most knowledgeable about troubleshooting mesh issues, especially with a completed DynDOLOD output in the mix, so this was mostly just me trying to brute force possible resolutions without being able to parse/tinker with the DynDOLOD output itself. While it yielded no results on my end, maybe this info can help with your more seasoned diagnosis. It indicates to me (and again, I'm pretty inexperienced) that the construction of the mesh itself isn't the root cause of the crash, since even across multiple different versions of the mesh, sblacksmith.nif still appears in the crashlog. If it does end up being related to DynDOLOD, would I need to regenerate LOD in order to test solutions? Is there a "mini-run" I can do, localized to the Solitude region, to save on generation time, in that case? Let me know if anything jumps out about the issue, or if there's some other things I can try in the meantime. Thanks!

Hello, currently getting repeated crashes while attempting to cross the estuary separating Solitude from the marshes north of Morthal. Using Alpha-156. Here's the crashlog https://pastebin.com/sWkypg9V where DynDOLOD is being pointed to, and the corresponding DynDOLOD generation logs are attached. As always, thanks for all your hard work. EDIT: Forgot debug log, uploading now and will post it here. EDIT 2: Here's the debug log https://ufile.io/vzz9bnx8 DynDOLOD_SSE_log.txt

I'm not sure if that's the case either, but I do know that ERM has, for the longest time, pretty much sat in the lowest part of the left pane of MO2 (followed only by Icy Mesh Remaster, along with DynDOLOD Add-ons and outputs). I also found that, in returning to the same mountain ridge while using the NON-parallax ERM meshes and the same ERM texture pack I'd already been using, the problem was no longer present. This, along with the fact that the warping appears all over Skyrim (not just outside of Falkreath) is pretty much enough to convince me it's a parallax issue, not an issue with COTN - Falkreath specifically.

I wish it were that clear-cut, but unfortunately, the reason "COTN - Falkreath" appears to be the last overwriting mod is because ERM has no ESP file. More Informative Console only detects plugin priority, not accounting for loose meshes or textures. Your suggestion is a good one, nonetheless.

Here's one video demonstrating the issue, btw, in case the author does take notice - along with shots of the More Informative Console window pertaining to the problem model. P.S. I have no idea if the streamable link I posted is going to expire in the near future, I'm not really familiar with using that site. I have the video saved on my PC, so if it needs to be reuploaded at any point, lmk.

That makes sense - creating the illusion of depth for uneven surfaces, subject to illumination by different and overlapping light sources with differing angles of incidence does seem like it could very plausibly lead to wonky visuals, especially with respect to shadowing. To be more explicit, I think the issue is related to parallax implementation, rather than parallax function - the texture stretching looks pretty otherworldly, for lack of a better term, not just mildly jarring. I can and will grab screenshots later (I actually took down a short record of the places with the highest densities of warping/stretching), but until I can, I guess a decent comparison would be like... seeing a part of the mountain if viewed through some source of gravitational lensing? As an aside: would you happen to have any recommendations for nice non-parallax mountain mesh/texture combos? It's of course super subjective, but If I end up exhausting available parallax options, and proving less than equal to the task of fixing these issues, I'm super interested in trying out versions of maybe MM or ERM without the feature.

It seems like this mod isn't actively being discussed at the moment, and I'm not exactly a "forum regular", so take my opinion with a healthy portion of salt. That being said, drawing from my own experiences and (numerous) claims from others which echo my own... this mod probably needs a good deal of work before it's ready for inclusion in an official guide. If you walk far enough along the length almost any prominent mountain ridge with the ERM Parallax meshes installed, you will pretty reliably find at least one instance (or usually, multiple) of stretched/warped mountain visuals. I will be the first to admit I'm not super experienced with these kinds of mods and their mutual interactions, so I started out by ensuring it wasn't a problem with the textures being used - the fact that I had been using the ones provided in the optional files section of ERM's mod page, with those files winning any and all conflicts with my load order, should have clued me in to the fact that the problem was local to the mod itself. Even after coming to that realization I ended up taking some pretty obscene and time-consuming measures to try and resolve the problems (which may sound odd considering these are pretty much just loose meshes, and so overwriting everything should be a fairly straightforward solution), and see if it was by any chance user error, to no avail. In my own encounters with the problematic visuals, they seem to crop up with the highest frequency along mountain ridge "saddle points", ie places where the stone surfaces inflect. It's left me - an uninformed amateur in the texture/mesh/landscape visuals modding space - a bit lost with respect to choosing a mountain mod at this point. Majestic Mountains doesn't really offer great terrain blending on its own (maybe the Terrain Parallax Blending Fix could help with this though, haven't really explored that yet), which is why I sought a solution in ERM. Then, after trying and failing to grapple with the issues detailed above, I moved to Majestic Mountains Complex Material. However, MMCM necessitates the simultaneous use of either Majestic Landscapes. or the corresponding version of Atlatean Landscapes (the "Majestic" variant) in order to achieve comparable blending; I don't really like the aesthetic of the former, and the latter still has very jarring blending issues in a lot of places. As a last resort, I tried out the base version of Atlantean, which comes with its own mountain meshes and textures, specifically geared towards terrain blending with the help of Terrain Parallax Blending Fix, and that's the closest I've come to an "unproblematic" solution... unfortunately, I could not for the life of me get mountain LODs to look anything close to my preference while using it. So, I have come to stand before the almighty Lords of STEP, hat in hand, seeking your profane knowledge: this likely isn't the right place to ask (if I need to move this to a separate thread, lmk, and I'll do so) what mountain setup do you guys use/suggest?

I'm playing on a 1TB SSD (with a lot of space still available), but I don't have a grass pre-cache yet so I'll give that a shot - thanks!

Hi again, STEP! Pretty much as the title says: sometimes, when entering a new cell or just a new place where a patch of grass should be, I have to stand in the area for upwards of 10 seconds (and sometimes open the perk menu when that doesn't work) to get the grass to load in. It's inconsistent, too - sometimes it appears instantly, sometimes it doesn't appear at all. I'm NOT running grass LOD at the moment, which I plan to tinker with over the weekend, but I'd like to solve this long-running problem I've been having before that; I'm hoping that there's a known cause for something like this, and that it's not just a CPU limitation. I'll attach my ini files (including the one packaged with Skoglendi, the grass mod I'm using) to this post as well. Skyrim.ini initweaks.ini SkyrimCustom.ini settings.ini SkyrimPrefs.ini Skoglendi - A Grass Mod.ini

WOW, I didn't even notice that - not that I really would've known to look for it, I'm pretty much a novice when it comes to the actual mechanisms behind LOD, but I can tell you I certainly did not set it to that manually. Thanks so much for pointing this out. Will do! Exactly my reaction when I saw this haha

Thanks for sticking with this - here are my settings: [TerrainManager] bShowLODInEditor=1 fBlockLevel0Distance=58000.0000 fBlockLevel1Distance=100000.0000 fBlockMaximumDistance=200000.0000 fSplitDistanceMult=1.1000 fTreeLoadDistance=70000.0000 I've also attached my Skyrim.ini and SkyrimPrefs.ini files, in case a complete lookover would be helpful! SkyrimPrefs.ini Skyrim.ini

Yep, it's LOD related after all, good call; note the trees in this video: https://streamable.com/64ivk2 I wonder if it's the snow in particular causing it? Let me know what might be helpful to upload (like modlist, DynDOLOD logs, etc) - currently using DynDOLOD 3 (Alpha-128 and most up-to-date Resources), Dyndolod NG dll (Alpha-6), Happy Little Trees and the DynDOLOD Add-On for it. This probably accounts for why the LOD Unloading Fix resolves the issue (temporarily). EDIT: It seems, upon closer inspection, the LOD Unloading Fix doesn't actually even resolve it temporarily - if I hit the "Fix LOD" option and then walk even a hundred or so feet, the bug can be seen on trees again.

Will do - it sorta appears at random, no idea what actually triggers it, so I'll go looking for more and report back.

Hi guys, I've been having an issue related to the way distant light appears on mountainous rocks and trees, and I have no idea what potential sources might include. I am happy to share my modlist and any relevant DynDOLOD settings, but first I thought I'd share an image of the issue so that if there's a simple cause/fix, someone could let me know. In the attached image, the rock formation to the right is demonstrating the problem I'm having - interestingly, using the "Fix LOD" action from the MCM of LOD Unloading Bug Fix does remove the weird jagged light objects, but eventually they return if I travel far enough in game. Let me know if there's anything else you need, and thanks in advance!

Damn, thanks for letting me know; is there any way to work around this? Would you happen to know if a fix being worked on if it's currently not possible to skirt around it?