z929669

Tagged for testing. This is a contender with MM and is highly vanilla compatible. It also has LODs now. I prepared straight vanilla compares on the ERM LOD mod page.

Sounds like a LOD issue. Are you running DynDOLOD? What version of the Alpha if DynDOLOD 3? Are you using the LR Bugs Workaround via DynDOLOD DLL NG? For DynDOLOD troubleshooting, post in the DynDOLOD Support forum in accordance with requirements specified in the OP.

You said you followed the guide to the letter, but I suspect you missed some things: When updating DynDOLOD 3 Alpha, REMOVE all content in the folder of the previous version before moving in the updated files. Always install the latest version of DynDOLOD 3 Alpha. You should be using 122 now. Do not install DynDOLOD app as a mod. Install DynDOLOD Resources SE Alpha-34 and DynDOLOD DLL NG Alpha-5 as mods and in that prioritization order. Disable DynDOLOD DLL if you have it. Set Expert=1 in DynDOLOD_SSE.ini to gain 'expert' mode. Also modify the ini for all other settings indicated by the guide To meet the requirements for LR Bugs Workaround, you must follow the guide, which explicitly instructs to clean all vanilla plugins that apply. This is a requirement for using DynDOLOD DLL NG. If ITMs or USRs are detected, the LR Bugs Workaround will not be available. There are at least 40 vanilla plugins that need to be cleaned as specified in the guide. All of the above is indicated in the guide, so you have missed something. If you experience further issues, then post on the DynDOLOD Alpha forum with logs as specified in the OP. Sheson doesn't support our guides, only DynDOLOD, so mentioning guide instructions will get you nowhere. He has nothing to do with our guide recommendations. He only will point you to the official DynDOLOD doc.

This looks like a general error cause by Windows Security or antivirus. It can also result if you have your modding assets located in UAC-controlled paths like %USERPROFILE% and %APPDATA%. See this post for a method to resolve. Also see the OP for exactly what logs to provide and upload those as well.

I 100% agree. Thanks for posting these compares. It demonstrates the fallacy of assuming that higher-res textures are better. Books should be 512, IMO. But if people want to run 4k, then they should consider using something custom built from scratch. There's a limit to upscaling, and this certainly shows it.

Testing some new LODs and correcting errors, but one error makes no sense. This seems like a DynDOLOD reporting mistake, but I may not be aware of something not so obvious. The LOD model has the correct-named strings of the full model, and texture paths match. For some reason, DynDOLOD is calling out the string name of the full model, "RockPileL03Wet:8" but it's not even represented in the LOD model: Error: Warning: Textures do not match for "RockPileL03Wet:8": textures\landscape\mountains\mountainslab02.dds in rockpilel03wet.nif -> textures\landscape\rocks01.dds in rockpilel03wet_lod_0.nif Logs with the full/LOD meshes EDIT: Cancel that^ ... we've found the problem. The RockPileL03Wet:8 string should be the RockPileL03Wet:19 string. Now I'm wondering how DynDOLOD caught that, since neither of these is used by the LOD model. Does the answer lie in the plugin reference?

Read this article to better understand. Also see this poll topic post and the OP and other posts for more info. If an author updates a Main File without also syncing the file version to the mod-page (global) version, then that file will be flagged as outdated by MO. Any files in other sections are global-version independent and do not consider the mod-page version. In the Armor Mesh Fixes example, the global version is 1.1. The Main File version is 1.0 (flagged for update by MO) The Update File is 1.1 and will not be flagged for update by MO unless a file with that exact name in Update Files changes version to something different. It doesn't even consider the global version or the Main File version. The same is true for all file sections other than Main Files. With Armor Mesh Fixes, merging works for the Main File, because the Update File version applies to the Main File version, which sets it to match the global version. If some other Misc File also was v1.1, merging it with the Main File in this case would also not be flagged for update. More often than not, the other files being merged have versions != to the global version and merging will cause MO to flag the file for update. Separating all downloads into separate mods will always yield the highest-fidelity version tracking with MO. In rare cases like AMF, this isn't true, but it's really coincidence more than anything else. MO's (aand Nexus') version tracking/maintenance needs fixing.

You are likely not using the latest DynDOLOD Alpha 122, or have not installed the latest Resources for that version. Read the DynDOLOD OP for requirements.

An example of this is Veydogolt Trees, and I haven't found any problems affecting the DynDOLOD outcome other than the log warnings; however, I suspect this could preclude such mods benefiting from certain DynDOLOD features now or added in the future (in addition to being bad practice in general). That mod has bark normals named like treepineforestbarkcomp_pine_9N.dds and branch textures named like Spruce05_Normal.dds

Good callout. There was definitely some confusing redundancy there. I've moved around the instructions a bit such that the ENB setup is now located with the ENBSeries mod instructions. I think this makes things clearer in addition to removing the redundancy. You probably didn't see any performance impact with the ENB, because the ENBSeries binaries hadn't been installed yet (ENB requires the binaries to work). Follow along again starting at 21-Post-Processing, and let us know if it's better.

You seem to have issues with your animations mods/config. You may need to gen animation files via Nemesis or whatever, but maybe confirm first by disabling all animations mods and testing on a new game. Don't forget to enable all plugins when disabling/re-enabling mods and sort with LOOT. Always clean dirty plugins, including vanilla. We describe that in our guide.

If you have a LR, set z to -30000, enable parent on the ref, and set to player and "enable opposite of player" flag. That tells DynDOLOD that the refs are suppose to be disabled and it should ignore them. Then in the normal plugin author place new references to replace the vanilla ones. This is the reason RWT has an ESM and ESP. More info on this pinned topic. No idea about the CK question

It's in your save game? Test with a new game to verify. Try a clean save procedure if issues persist.

Binary and Start in both have spaces. This should be OK, and I assume MO handles the spaces properly by passing these strings to the OS in quotes ... otherwise, there would be known issues with lots of people. I actually have a couple of examples of this myself with no issues. Your Arguments are in quotes, so no issue there. I mainly meant to check your entire setup against our setup guide to verify you have a good config on it's surface. Particularly with respect to game/modding paths and MO installation. Most people's issues are related to things our setup guide preclude.

I'm not familiar with using those apps, but your issues are almost certainly related to configuration and not java, etc. Those are most likely rabbit holes detracting from the issue. First off, don't install MO or the game in UAC-controlled paths under %USERPROFILE% or C:/Program Files or C:/ProgramData. Second, enclose the paths you are adding to your MO executables in double quotes (MO may ultimately do that at runtime, but IDK) ... or better yet, install everything in short paths with no spaces. See our System Setup Guide for details on ensuring a 'good' config for modding - where to install and how to set up Steam and MO.

IMO, vanilla Skyrim is overly bright on my system. The OOtB brightness and image space is waaaay too bright, so I have quite the opposite XP. Cathedral alters this slightly on average to be maybe a bit darker, but it all depends on the weather and location. I don't think 'people' need to increase their brightness but rather "certain people" may benefit. The same is true for the inverse correction to darken things. Game brightness is very dependent on hardware, software, and game settings. Coupled with weathers and post-processing, it gets even more variable. Throw in user preference, and it's all over the place. We do as much as possible to recommend standards via game settings and our lighting/weather setup with/without ENB, but results will vary. EDIT: as I also mentioned, Windows 11 HDR enabled/disabled and related settings may not be supported by the game, but it does have an impact on the game's display (not necessarily good/bad but depends on the system)

In addition to what Mouse provided, please see this wiki article, which describes the differences between Profiles and Instances and use cases for each.

Your issues are are hardware/software specific to your setup and not generally applicable to others. As mentioned previously, you will need to make adjustments to your setup (probably in your driversoft, HDR, and monitor settings). Any ENB preset should complement the weather/lighting mods being used and not alter it in terms of lighting/ambiance. The ENB should and will make things a bit darker, but your situation seems to be unique (or your preference).

I use AMD and have found that simply killing all 'AMD' processes (most notably Adrenaline) prior to launching TexGen/DynDOLOD resolves the 'boatware' lag issue. This allows benefits of said software outside of LODGen processing.

If you have assets required in your desktop path, remember that Windows has at least two shortcut links to this path (and anything under %USERPROFILE%) for backward compatibility with legacy apps. It's never a good idea to run programs from %USERPROFILE% paths or that need resources from this path. This is probably why Dyndolod is returning \C:\ Change the location of everything to a path on your C:\ drive like C:\Games or C:\Modding rather than C:\Users\. This path is also under UAC 'protection' All your problems will likely go away then.

Performance in Riften is always a bit more taxing than most other places because of Aspens Ablaze. The big ones have lots of triangles.

Why would you not want the trunk to appear in the LODs? That kind of defeats the purpose of LOD. If you mean that you mostly only see the trunks in LOD masking the crowns, then your issue is probably due to the branch texture alpha and mipmapping: re-save the crown branch textures using a higher alpha mipmap coverage threshold using Texconv or NVIDIA Texture Tools or the like. 127/8 is usually best, but it varies. If you see artifacts of trunk billboards, you can do just as sheson has indicated, skipping the hybrid piece as described in Standard LOD models of that guide. Sheson also mentions the 'decimation' process to reduce the triangles of LOD (in addition to stripping out the wasted NIF nodes and data). This is a more advanced process requiring some modeling skills in Blender or the like and not practical for most people. Also note that that guide explains one method for constructing the hybrid assets and works well for < 10 trees or so. It's better to use the 'strip-from' method for doing a lot of trees (and DynDOLOD xEdit scripts). That guide is not updated to completely explain that process, but it's alluded in the Hybrid LOD models section.

EVLaS doesn't 'break' anything with AI detection. AI detection is simply not aware of anything that EVLaS and post-processing do in terms of lighting. So if a shadowed area looks really dark to you, it may not look that dark to the game. To get an idea of what a low-light area is, you can toggle ENB using Shift+F12. EVLaS will only impact outdoors, and really only very early or very late in the day. These issues are similarly complicated by your weather and lighting mods. Step is configured to minimize those impacts though, so your main obfuscations are EVLaS (exteriors) and ENB (exteriors and interiors).

This is exactly correct.

I'm assuming the plugins could have some conflicts related to scripts or other animation assets referenced, so I could imagine the rule of one causing issues with related references.