z929669

Thanks for the context. I honestly don't remember using WB for merged patches, and too bad zEdit is deprecated somewhat. It's probably still good for zMerge, since I see it being used in Lexy's guide for that purpose still.

I haven't used WB in years now, but creating a 'merged' patch wasn't possible historically. A Bashed Patch only used to merge leveled lists and not other records. Perhaps this has changed? There's several tools available for merging plugins, but it may be that only zMerge (comes with zEdit) is the most contemporary. Mator Smash may or may not be deprecated.

Yes, the offending instruction was removed, and some context was added for manual restoration of the vanilla masters. If you use Steam to verify the files, that's the easiest method (so don't use the manual method under the spoiler): https://stepmodifications.org/wiki/SkyrimSE:2.2.0#Restore_the_Original_Vanilla_Masters

See my last comment. Not identical, but similar effects with completely different implementations.

Ambient occlusion is similar in the game versus ENB, but different implementations. I don't know much about it really. If you don't see that option in BethINI, then maybe you are running the beta version that may still lack features. not sure, but you're in luck, since our resident @DoubleYou is the author/developer of BethINI and knows more about Bethesda game INIs that just about everyone outside of Bethesda devs, I'm guessing

It's been a while since I was into this one, so I forget some of what I did prescriptively when working on CL-CG ... Load up the grayscale diffuse PNG. First thing is to choose a 'shape' ... I think I used the right one, but it doesn't matter so much with plants/foliage. Just be consistent. It matters a lot more with shapes having an expected appearance like a ball or a bowl: Looks like I saved my preset, and here's what it looks like I probably did for most of them (you can create both in the same session ... see tabs): Mind you that I'm not a professional GFX artist. Just an amateur with a lot of XP I found these settings after many hours of testing results in game, because I wasn't happy with just about any CG grass mod I tested. All of them had too much reflectivity that it just looked bad in game at most ToD, IMO. The 'correct' way to do it is in the 3D application using standard procedures ... but that stuff doesn't apply to Skyrim and other Bethesda games, IMO. The engine is too old and limited to follow protocol. Lastly, when saving out the final DDS, I recommend using NVIDIA Texture Tools Exporter (Ps plugin or standalone). Save as BC7 with 'normal' compression quality and alpha-test threshold of 127 (but this can vary a bit, depending on the textures): Then there's the pixel and alpha trim at top of the normal to set as well, which takes a bit of doing to figure out. It's simple really but critical and can be tricky to figure out at first. Can't really help here so much, but Photoshop has lots of help with Google. Download the CG specifications guide here. Lots of stuff from that is beyond what you are doing, but it gives you the CG specifications nicely. Tip: record macro in Ps helps with > 3 grass textures when you are ready to build the final product. It's a lot more tedious work than it seems.

With ENB, disable ambient occlusion. Otherwise, enable it. Further guidance (read the text when looking at each screenshot) In enbseries.ini and all weather INIs, set [SSAO_SSIL] UseComplexAmbientOcclusion=false It's fine to set the following in enbseries.ini, but it comes with a performance hit of a few FPS ... [EFFECT] EnableAmbientOcclusion=true ... or just trust the ENB preset you are using takes care of the recommended settings in enbseries.ini

I should also note that testing with ENB enabled and CG disabled in the ENB will not be exactly the same result as testing without ENB. Further, the "without ENB" testing should technically be done without the grass-atlas textures ... but I'm not positive on that. I don't recall if the atlas version behaves the same without ENB as the standard diffuse-only textures. Maybe it's good enough. It's definitely different in terms of LOD though, so I would ignore LODGen while you are working on them.

Here's the progression for one particular CL grass. Re-worked diffuse Grayscale normal Specular Final (with ENB pixel in alpha and alpha channel visible. Diffuse uses alpha cutout, and normal uses specular as alpha)

Sorry, I should have read your post more thoroughly. What you see in the 'loaded' grass is specifically governed by the normal maps on the atlas of each grass texture. You would not want to mess with the diffuse area of these textures (top half) so much as the normals. What I found to work best --without going into a 3D application to develop the normal/specular maps based on the 3D models, which is far more advanced and time-consuming approch for beginners-- is to generate very noisy normals from the grayscale PNG versions of the original diffuse. This basically means that the tangent-space normals have a lot of surface 'diffusion' and are quite colorful as a result. Fine and medium details are most noisy, and large details less so. You can compare the normals I made in The CL-CG grass with those made for that same grass by others. Those I made are typically much noisier. This effectively mutes the reflectivity of the grasses a bit much like a glossy surface compares to a matte surface. Both reflect light, but glossy is much more reflective (which is the problem you are getting with low vs high sun angle). When making the final normal, you want to use the specular map of that same grass as the alpha of the normal. This means that the lightest areas of the specular will allow more of the normal to be visible through the alpha transparency (black is opaque and white is fully transparent) ... so you don't want the specular to be too 'strong' or bright. A tool like CrazyBump makes texture preparation a bit more convenient, but lots of other tools provide similar functionality. I use Photoshop to merge the final normals with specular alpha and to create the atlas with diffuse+normal.

See this sticky on Nexus and play with an 'alt2' grass billboard and ComplexGrassBacklightMask in DynDOLOD_SSE.ini.

First off, Time of Day (ToD) is governed by the weather plugin (in Skyrim, anyway, so assuming something similar for FO4, which I don't play). EnbSeries.ini TIMEOFDAY should be configured according to the weather mod if it differs from vanilla ToD. That said, I will defer to someone on our team that knows FO4 and what you are attempting.

Yeah, I forgot about the previous and subsequent instructions. Juggling too much ATM. thanks

Yes, that's probably the issue. Since those of us that have been using these tools for years have %LOCALAPPDATA%\Skyrim Special Edition\Plugins.sseviewsettings, all of our xEdit-based tools use this config (xLODGen, DynDOLOD, QuickAutoClean, etc), so testing the "new configuration" experience is quite tedious and disruptive to all the working parts on my system without a VM or the like. I can certainly remove those instructions, but then the question is how to instruct people to preserve (or reacquire) the vanilla files to keep Steam happy. I think there are two different instruction sets to accomplish that, based on the xEdit env.

The binary-check approach is suitable when you are uncertain what mod/plugin is causing issues. Note Mousetick's previous question: Since we have some clues about the potential problem plugins, you could start by disabling only mods providing these plugins and testing (with the exception of the USSEP and vanilla plugins): Possible relevant objects (8) { [ 9] TESObjectACTI(Name: `Catapult`, FormId: 0005A5FE, File: `Skyrim.esm`) [ 9] TESObjectREFR(FormId: 000AC19D, File: `Skyrim.esm`, BaseForm: TESObjectACTI(Name: `Catapult`, FormId: 0005A5FE, File: `Skyrim.esm`)) [ 43] TESObjectCELL(Name: WindhelmCandlehearthHallExterior, FormId: 00038382, File: `S3DTrees NextGenerationForests.esp <- Unofficial Skyrim Special Edition Patch.esp <- HearthFires.esm <- Update.esm <- Skyrim.esm`) [ 61] TESNPC(Name: `Luna`, FormId: 00000007, File: `MVF1FollowerBeta.esp <- Skyrim.esm`) [ 61] PlayerCharacter(FormId: 00000014, BaseForm: TESNPC(Name: `Luna`, FormId: 00000007, File: `MVF1FollowerBeta.esp <- Skyrim.esm`)) [ 83] BGSLocation(Name: `Eastmarch`, FormId: 0001676A, File: `Keld-Nar.esp <- Unofficial Skyrim Special Edition Patch.esp <- Skyrim.esm`) [ 95] TESWorldSpace(Name: WindhelmWorld `Windhelm`, FormId: 0001691D, File: `Provincial Courier Service.esp <- Immersive Citizens - AI Overhaul.esp <- Complete Alchemy & Cooking Overhaul.esp <- WindhelmFakeWindowsFix.esp <- Map Markers Complete.esp <- Windhelm Entrance Fix.esp <- The Jarl's Household Guards.esp <- 1B04ExtraNPCs.esp <- Inigo.esp <- Thieves Guild Requirements.esp <- S3DTrees NextGenerationForests.esp <- 3DNPC.esp <- Cathedral - 3D Mountain Flowers.esp <- Unofficial Skyrim Special Edition Patch.esp <- Dragonborn.esm <- HearthFires.esm <- Dawnguard.esm <- Update.esm <- Skyrim.esm`) [ 112] BGSLocation(Name: `Windhelm`, FormId: 00018A57, File: `Bashed Patch, 0.esp <- Ordinator - Perks of Skyrim.esp <- DeadlyDragons.esp <- Unofficial Skyrim Special Edition Patch.esp <- Dragonborn.esm <- HearthFires.esm <- Dawnguard.esm <- Update.esm <- Skyrim.esm`) } Always, re-sort with LOOT prior to testing. Also disable any dependencies that might use these as masters. Once you have confirmed the problem, you can begin looking at the related references to isolate the offending record(s). I'm not great at interpreting these crash logs to the specificity that some of the other folks on this topic are able to do. These are the basic first steps though.

It's been about a year since I last use QuickAutoClean on the 44+ plugins that need it in our lineup according to LOOT, and I honestly don't recall the details. I could've sworn that backups were created then, as I don't recall using Steam to sync back the originals after saving out the modified plugins into a mod.

Regardless of how many mods you have, a binary testing algorithm (disable half, test, disable other half, test, disable half of problematic half, test, etc.) ... EDIT: ... erhm, I meant to type "is pretty efficient regardless of the mod/plugin count". If it's 4 mods, it takes a max of four attempts to find the problem mod, if it's 4000 mods, it only typically takes a few more steps (it's essentially a Bayesian approach, which is why it's largely agnostic to the total count, especially if you have a-priori suspicions). @swsjr Use this method to quickly find the problematic plugin. If the problem is in your save, then this method won't work, obviously.

You must be certain that this option is ticked when you click 'X' to quit: Otherwise, type Ctrl+s to save. Also be sure you check Overwrite if you didn't follow the Tools instructions

Moved relevant posts to this topic

No, I understand the conceptual differences quite well. I don't feel like you really read my last post where I tried to emphasize the nature of a static custom grass cache, generically speaking. The grass cache, by definition, is static and governed by the grass mod (plugin) itself as well as its interaction with other plugins in the LO. I get what you are saying. I agree with it and also agree that the game/NGIO distance settings effectively dictate rendering of static grass from the cache without ability to dynamically impact grass not loaded in the active cell range. Only NGIO can do that. I won't pretend to know all the details of the plugin-level intricacies ... not because I'm unable to comprehend them but because I will not retain those details in my mind, so I care not to implant them at any given time. I have too many other things to do, and my memory just doesn't work like yours and DY's. I think intuitively and conceptually, and I intuitively and conceptually grasp the paradigm differences between use of grass cache and LOD in the different game runtimes w/wo the presence of NGIO (which is the key difference here: NGIO installed and running during PLAY, or not). You could run 1.5.97 in the same way as 1.6.xxx, but why bother when you can run NGIO and gain it's benefits making loaded grass behave under the same constraints the cache was generated (a snapshot of each loaded cell governed by NGIO and cast as a static rendition in the distance). I'm a reductionist. I've agreed with you multiple times that the guide could be improved. I emphatically disagree with you that the guide, in it's current and original states, is doing a "disservice to the community" OR that it has "incorrect details" or "falsehoods". It has a bit of redundancy, fails to clearly delineate use for cache benefits alone vs LOD (although that has been resolved for the most part, IMO), lacks intuitive 'flow', and fails to explain things to the level you just did (although DY has added lots of technical stuff that conveys much of this, albeit it's a bit disjointed and difficult to digest). This detail is simply not needed to achieve the desired result in either runtime. The guide has always been beneficial and has always provided information in one place that is not available anywhere else. There's execution and understanding. We're focusing on execution (i.e., "Quick Start") rather than understanding (i.e., "Additional Information"). This contributes to it being a bit disjointed as you so clearly reiterate. You never answered my question, BTW ... Are you really saying that you didn't learn a few things from it and didn't ultimately save time juggling with your own inference because of it? (i.e., if you can admit that, it was actually of benefit to you). I think your argument is going a bit too far in support of itself is all. In so doing, you are not allowing yourself the ability to grant some quarter here, since it would soften your point (I assume). I'm in agreement with DY is all. Only those two distance settings are 100% redundant, but they align with our recommendations regardless of the game runtime, and I think they belong there for the sake of consistency of our recommendations for rendering grass with or without DynDOLOD (in either runtime env). I agree that we should support both runtimes. It has been improved from your and other previous criticisms but could still use improvement. Again, this takes careful thought and time, which are in limited supply with all the other priorities on this site and in RL. I would love it if you contributed. It is a wiki after all, and you have ability to edit. Copy/paste it to your user page if you want and change it as you see fit. I've no doubt it will be beneficial in the end. If I've stated any falsehoods or misinformation here, do point them out (preferably with specificity rather than as fodder to make your point again). Rather than continued debate to reiterate points clearly made, I think it would be more productive to act. EDIT: I see DY has been spurred to address some of the issues pointed out ... progress

The only mandatory settings for creating the grass cache are: UseGrassCache = True ExtendGrassDistance = True OnlyLoadFromCache = True Aside from that, only grass render distance settings have no impact on grass cache behavior. Some of the others may or may not, but it's not clear in any documentation, including NGIO. OverwriteMinGrassSize = iMinGrassSize (skyrim.ini) ... this almost certainly controls grass density of the static cached grass, so it should be noted likewise. Similarly, GlobalGrassScale almost certainly controls the size of the static cached grass, so it should be noted likewise. It could also be noted that grass in the loaded cell will not honor these settings unless NGIO is active. The only exceptions are the Overwrite* settings, which are part of the game and potentially overridden by NGIO but not necessary. DY did some testing and recommendeds ExtendGrassCount=false (default in NGIO is 'true') ... and provided a full explanation in that guide that I don't think can be easily accessed on-demand from any other source. Aside from that, the simplest conveyance of this info is to simply install NGIO and create an "NGIO - Create Grass Cache" INI override file with: UseGrassCache = True ExtendGrassDistance = True ExtendGrassCount=false OnlyLoadFromCache = True The relevant NGIO and DynDOLOD settings under Additional Information are accurate and superior to the NGIO doc, AFAIK. That could be linked from this section. Note that DY even found that DynDOLODGrassMode will conveniently override other relevant NGIO settings to ensure things work properly without having to change them (or game INI settings) manually. What I noticed is missing after further scrutiny is advice to disable the "NGIO - Create Grass Cache" INI override, and for LOD use, create/enable a "NGIO - Grass LOD" INI override with: ExtendGrassCount=false DynDOLODGrassMode=1 I think we've acknowledged that the guide can be improved to be more organized with a better flow. Someday I will do it if neither of you guys does it first. For now, it serves it's purpose adequately and conveniently, IMO. If you are attributing these statements to our grass LOD guide, I couldn't disagree more with all of them. Removing access to this guide would be the disservice. Of one thing I'm certain: In it's current and recent-past states, this guide is essential reading to understand NGIO grass caching and the best way to configure a custom grass cache for DynDOLOD use. Are you really saying that you didn't learn a few things from it and didn't ultimately save time juggling with your own inference because of it? _______________________________________ With respect to the following, see the original Topic: I think you are seeing a game limitation or an NGIO limitation. I'm fairly certain that the best way to get better blending is to decrease your density so that everything is a bit more patchy if it bothers you. EDIT: after looking more closely, those patches are all associated with rock meshes, so my guess is that grass isn't rendered in those, since they are part of the rock models NGIO is avioding. Also, thank you for asking this question. Per our Grass LOD Guide (and DoubleYou's research):

Do you happen to know what setting/value caused the issue, or is it only something related to BethINI Ultra preset ... or just something possibly related to any BethINI preset?

I also use it as a reference, and it is quite valuable to me "as is". I also think it's useful to most other people in this context; however, I do get the point that it's not straight forward for beginners (and never really could be unless the beginner is a quick study with adequate, self-service technical aptitude). After a quick review, I've made two simple edits to the first two sections of the guide that I think resolve this pretty well. The first 7 steps apply to everyone, regardless of grass LOD being intended in the end. The only piece I'm not satisfied with is Step 5 (downgrade), which only pertains to those intending to use 1.6.xxx runtime in the end. This is stated, but I would begin with this optional at Step 1 (after my 1.6.xxx build is 100% polished). It's just a nitpick though. It's worth a look, as it's always possible I missed something. EDIT: We could also modify the title of the page as "Grass Cache & LOD Guide", which would increase relevance via organic search for those interested in Skyrim grass cache.

Glad it helped. You might consider using BethINI to sort your game INIs using well-tested settings at various performance presets. Maybe this will resolve with JK's

I don't fancy thinking about trying to upgrade a laptop.