z929669

Here's some Complex Grass (CG) compares using different TexGen options. These are all based upon identical TexGen and DynDOLOD processing from scratch (i.e., no "Rebuild Atlas" or "Execute LODGen" shortcuts, as I found those produced inconsistent results). I'm using a 4K (2160p) system. See my sig for PC specs. The only differences in the outputs are single variables in TexGen processing, which are noted. Relevant mods: Cathedral Landscapes Complex Grass for ENB (v1.2.0) EVT (v2.3.0b) LOD reference 7AM, Texture size min=32 7AM, Texture size min=64 12PM, Texture size min=32 12PM, Texture size min=64 6PM, Texture size min=32 6PM, Texture size min=64 Increasing the min size to 64 seems to have a slightly better outcome under 4K at least. The LOD grass is brighter at 32, presumably due to higher starting mip levels and less accurate alpha. BUT, at midday, 32 pixel min looks better, since the normals are not casting as much light when the sun is high. All following compares use Texture size min=64. 7AM, BC7 Quick 7AM, BC7 Max 12PM, BC7 Quick 12PM, BC7 Max BC7 Quick 6PM, BC7 Max BC7 Max has a slightly better outcome, but again, this does not hold true at midday, presumably because more distant LOD grasses lose some lighting due to the more preserved alpha under BC7 Max. However, nearer LOD grasses at midday are slightly brighter with BC7 Max. 7AM, HD grass smoothness=0 7AM, HD grass smoothness=50 12PM, HD grass smoothness=0 12PM, HD grass smoothness=50 6PM, HD grass smoothness=0 6PM, HD grass smoothness=50 Smoothing the normals tones them down a bit, reducing the lighting, which works well in all cases except for midday, where grass LOD is once again too dark.

Just following up with some info relating to this^ that I have gleaned since we resolved the complex=true issue. I get 70 text files when choosing 32 as my min resolution in TexGen. When I choose 64, I get 73 variants. I'm not sure why, but it seems like evidence that setting a 64 pixel min might be interesting, particularly for 4K resolutions. I'm currently testing this hunch and will post back with some compares and other data relating to CG. In order to consolidate information, I've posted some screen compares on the CG support topic. Please voice your opinions or advice if you have any. Thanks

So are you running pure vanilla or with added NPC mods or mods that may touch factions? If you are running such mods, it's more than likely an issue with one of them (or their scripts if present).

LegacyoftheDragonborn.esm might be the wrong version for JKs Castle Volkihar - LOTD patch.esp or vice versa. Research those mods, and install the correct versions of each for your game. Revisit the LotDB requirements.

If you game is crashing when you disable the DynDOLOD resources, DLL, scripts, and outputs, then the cause is not DynDOLOD. It's just a coincidence. There's no need to uninstall DynDOLOD. It's just an application outside of your game directory. Just disable all of the DynDOLOD mods I mentioned. Use a mod manager like MO. Sort your plugins using LOOT. Use BethINI to establish correct game INI files. Update all runtime mods related to SKSE to the proper versions for your game. Uninstall mods with problematic plugins. You can follow the Step guide to establish a working baseline modded build.

Moved into the DynDOLOD Support forum. To get your issue resolved quickly, please post your log files.

I haven't seen or tried it, but it sounds like a specular is used to construct the normal. I don't know if xLODGen produces it from the diffuse or if it's used if present beforehand. I would see the changelog or ask sheson aobut it.

I made some significant updates to this mod: Version 1.2.0 Optimized the ENB-CG trigger pixels (for real this time). Color management had been altering the intended outcome previously, and this has been resolved finally. Corrected hue and saturation of snowy grasses. Optimized the white balance of snowy grasses. Snow grasses should complement snowy landscapes much better now. Optimized mipmaps for all grasses so that full grasses don't fade out at the maximum render distance and yet don't bleed into the alpha borders.

Apologies for jumping in ...heroic effort keeping at this testing! It's not trivial, and I for one appreciate it when members keep at it like this. Same goes for you, sheson. The tenacity is remarkable and much appreciated on both sides. @Kattmandu Could you narrow down to one of the following, or must all three be disabled to avoid a CTD in your testing with the original? Spell Perk Item Distributor disabled Storm Lightning disabled Oxygen Meter 2 disabled I suspect Storm Lightening as the most likely suspect if indeed the CTDs are not synergistic and dependent on all three.

I converted my changes into a PR, and the LOOT ML has been updated. The warning is gone now

xLODGen and DynDOLOD/TexGen all produce their output in default folders under their respective application directories. You must then move these outputs into new mods in Vortex. You may need to let the respective applications compress the outputs into archives in order to install them as mods with Vortex. We don't use Vortex here, so there may be something spexific for that. Try this YT video.

If the LO doesn't seem to change, it doesn't mean it didn't. Run external LOOT again, and you should get a LOOT message that your LO hasn't changed. This confirms your LO is sorted in compliance with the latest LOOT master list.

See sheson's previous message. Click on the error link to discover the problem plugin. Even if you have cleaned all of the vanilla masters, and LOOT shows no warnings, LOOT probably does not have the data for the problem plugin.

That info is not exposed on the forums. Just continue on as normal, and you will trigger the advancement when you hit the threshold.

You have three points now. One for logging in and one each for two reply posts you made. All interactions yield points, even selecting a best answer in a Q&A forum. Actually, you have 4 when including the forum you followed. You advance to Citizen at 20 points.

The MO VFS can only reveal actual files on your system. Those files are just mapped onto an analog of the actual game path from the 'real' file locations (Downloads, Mods, Cache, Profile, and Overwrite). The reason you don't see all these folders in the actual game directory is because they are compressed inside the game's *.BSA files. If you extract every BSA, you get this: ... these paths reside under your game Data directory but inside the BSAs. MO shows more, because each mod has it's own assets, and they are all combined in the VFS exlporer. Think of the VFS as soft links to real files in non-game real locations that are mapped onto the virtualized game path. Incidentally, Windows 11 has some bugs with the MO VFS, but they don't seem to affect me to any noticeable degree. I don't know the specifics. My example. My modded game working as expected (launch via MO), and base game works as expected if I launch via Steam (no mods this way though):

Are you using a mod manager? If so, which one? It should allow you to determine which mod provides that texture.

The test version resolved the issue. I generated only HD grass with TexGen using the Alpha 190 version twice to confirm the issue and included the logs and the txt files with the missing line from each run. I repeated with the test version, and all billboard txt files contained the Complex=True line. cg-tests

Thanks for the tip. I do not have Occlusion.esp active in my LO right now, as I'm testing DynDOLOD outputs and it gets in my way. I also didn't have it active when I checked, so if it's occlusion data, it may be related to WTT. I checked their posts and saw no mention of this location, but Nexus posts search isn't working right now :/

Noted. I will check this test version later today. In the meantime, here's a link to my last TexGen debug log, where 63/73 files were properly flagged. I'm not sure why there were 73 txt files this one time. I've also included the texture assets. Some of the recurring, ambiguously-flagged grasses are: fieldgrassTU (11) fieldgrassTU (9) fieldgrassTU (1) ffgrass01 flowergrasssaxifrage There are several others though. The load order hasn't changed in days. Only the TexGen settings were changed in the mentioned TexGen runs.

Is it possible that setting a nonzero Smoothness value could result in Complex=true not being written to the billboard txt? Perhaps the normal is changed such that it's not being considered as such by TexGen? As I await your response, here's some background... In an effort to find the best TexGen and DynDOLOD settings for my CG, I have regenerated TexGen and DynDOLOD from scratch about 7 times since I last reported my 'blue' CG issue being a fluke, and I similarly have had proper results (no blue grasses = all being tagged complex). As I mentioned previously, that seemed to have randomly resolved. However, it seems possible that when I alter Smoothness to be nonzero, TexGen fails to register the billboards of a few grass texture sets as complex. In hindsight, his is what I must've done the first time I reported this issue. That time, I tested with Smoothness=50. Just today, I set Smoothness=70, and was able to repeat the improper result. Because I'm as yet uncertain this one change is reproducible (or even causal), I will regenerate again with Smoothness=0 (default) to verify proper results once again. Then I will repeat with Smoothness=50. If the results are improper, I think this would be sufficient evidence that Smoothing the normal might interfere with CG data processing. I will reply to this post once I have the results. TexGen logs UPDATE: I reran TexGen to process HD grass billboards only 6 times with Smoothness=0. I always got 70 billboard txt files. Each run, not all files received Complex=true line: t1: 64/70 t2: 58/70 t3: 57/70 t4: 54/70 t5: 57/70 Obviously, some grasses don't get flagged consistently between runs. The likelihood of certain grasses to be ambiguously flagged is greater than others (there are specific grasses that are prone to not getting flagged, but sometimes are still flagged). I repeated a final time with Smoothness=70 and got 56/70. So Smoothness has nothing to do with it, IMO. Rather, there's something about the flagging method that results in the inconsistency, or there's something about the TexGen process and/or my environment that bugs out the process. Additionally, there's something about certain textures that make them prone to improper treatment. Each of the grass textures were constructed in an identical process, and each has 32x32 pixels in the lower left with r127, g127, b255. fortunately, it'seasy to quickly assess what txt files contain 'complex' string using Explorer, which searches within txt files in addition to file names (presumably, only if indexing is turned on). I verified that Explorer does this correctly by manually confirming that 12/70 text files lacked 'complex=true' line in t2 run. This issue might be common and would normally go unnoticed, because most people running CG use the standard GrassBrightness* values, which masks the problem for the most part. I just happen to be testing with a strong blue hue to verify that CG grasses are all being treated as such.

Nice find. In case you consider BitDefender alternatives, I use ESET AV. It has no such issues and is quite reliable in terms of threat protection.

More info on KPH mod page. I still have not gotten around to that one (nor has the LOOT team). I guess I'll need to make a PR after all.

Apologies, I should have read the OP more carefully. Defaults in instanced for me, and it works without issue. Assuming that when "uninstalled and reinstalled Skyrim", the game directory is totally clean of any third-party binaries and the like. Since this is specific to SSE/MO and other games run fine though MO, it has to be something associated with the SSE MO profile, SSE itself, or the SSE registry settings. Running via the Steam Launcher should properly set the registry. It might be a good idea to verify the game files via Steam and re-launch via Steam just to satisfy any lingering OCD. The only thing in the posted MO log I see that stands out is that there is no profile set, so it's reverting to default. Maybe set a profile, and tick all three boxes for profile specific * and auto archive invalidation. This is a shot in the dark. Can MO be configured to produce a more verbose log? I would also examine files under \Documents\My Games\Skyrim Special Edition.

Sheson actually is able to read crash logs, so I think he could help you finally succeed if you follow through on that topic. Just sayin'. ... anyway, I'm off topic here. Sorry.