z929669

The point I think to which Mouse is alluding is that any deviations at all can impact various aspects of the build in unpredictable ways relating to mod 'creep' of any content you may have added and relevant changes with respect to mods you may have skipped in the Step build. If your build is not 100% Step SSE 2.2.0 in its entirety, then we can't reproduce it to identify the problem. I can look in my own Step build to see if it's an issue, but I suspect it's not, or we would have discovered it by now. Not sure when I'll be able to verify one way or the other.

This is out of scope for the Step guide and should be raised with SkyUI team or the relevant mod authors extending this to SkyUI. It's really a minor 'issue', IMO.

OpenGL error finally with 126. I have the debug options active in my INI. Bugreoprt and logs. I'm rerunning again now and will let you know if repeatable. Second attempt succeeded without issue.

This looks like particle lights. I would look at your ENB config and whatever ENB you are using

This is the wrong forum to post such questions. Please make an effort to read the forum rules and search for the correct forum Moved from Mods forum to here.

It depends on if you are using complex grass or not. The INI comments and DynDOLOD documentation describe how to alter the configuration. Rather than expect that we'll be able to predict the result you want with your unique setup, please just read and test accordingly and let us know what works best with your grass flavor and weather/ENB.

It's back up. I'm still finding the sweet spot for maintaining the object cache.

You must have complex grass in your mod list to see HD grass.

There's really too much happening here to provide specific guidance other than do not unpack any BSAs or make changes to settings other than what's instructed in the guide. Revisit the guide/instructions/setup guide is all I can say. you obviously need to download and install "Step Grass" from the Nexus mod page.

I see now. I had left my full model renamed by the DynDOLOD CRC32 script in my xEdit output mod. Normally, I move/delete those out of the mod lineup to create the hybrid trunks/crowns: The error message lead me to believe that DynDOLOD was comparing CRC of the LOD with that of the full file, which it was, effectively. Thanks

Correct

You must test that. I have not tested with non-CG grass. Try setting GrassBillboard=3 or 5 to make use of backlighting at 0 and 100. Test again using the one without backlight. Read the INI and make adjustments likewise. The documentation explains it even more.

This error makes no sense to me. I have several of them for other trees. I included one example below. First, the LOD model does not have the same CRC32 as the full model. Second, the LOD model uses the full model CRC32 in the file name as per standards. [00:55] <Warning: LOD model meshes\dyndolod\lod\trees\treeaspen05_8b5f6a69passthru_lod.nif has same CRC32 as full model Meshes\landscape\trees\treeaspen05.nif Veydogolt.esp TreeAspen05 [TREE:0007614B]> Logs.7z

This is fixed

The 'alt' backlight settings we've been discussing mitigate the LOD lighting issues. LOD has no shadows and reacts a bit differently to light. You will just need to read the INI descriptors again and test using different values. We use CG grass and allow the backlight to have 25% effect. ; glowmap and backlighting mask textures replacements if corresponding texture slot is set by used grass billboard NIF ; 0 = keep texture defined in billboard NIF ; 100 = textures\white.dds ; other values generate and use a 4x4 pixel grayscale texture with RGB = 255 * value / 100 GrassGlowMap=0 GrassBacklightMask=0 ComplexGrassGlowMap=0 ComplexGrassBacklightMask=25 ; DEFAULT=0

Those are just descriptions of the effects in each of the four GrassBillboard2-GrassBillboard4 billboards that can be used for non-CG and CG grasses. Step uses CG, so we set ComplexGrassBillboard=5: ; Billboard template to use for grass LOD billboards created from "normal" grass without normal map textures ; 1 -> Billboard1, 2 -> Billboard2, 3 -> Billboard3 etc. GrassBillboard=1 ; Billboard template to use for grass LOD billboards created from "complex" grass with normal map textures ; 1 -> Billboard1, 2 -> Billboard2, 3 -> Billboard3 etc. ComplexGrassBillboard=5

I haven't tested without CG, but These are all new settings that impact grass lighting. Play with them to see what you get.

In my view, this is reason enough if only used for filtering/qualifying (as is glaringly obvious with respect to grass LOD in particular) ... as well as the concept of a "well-made mod". Thanks for clarifying further.

Just want to confirm what I know is likely true. per the doc ... BILLBOARD context: LARGE REFERENCE context: My presumption All base records defining models in game assets should have object bounds reflective of the bounds defined by the NIF model itself. While this isn't a hard requirement for rendering an object in the game, it IS a hard requirement for assessment of billboard creation and the grass/tree billboard *.txt metadata as well as for the LR definition. Context I'm working with a mod that replaces vanilla trees simply by using NIF assets corresponding to models defined in TREE base records of the vanilla plugins. The NIF, treepineforest01.nif, could be any (reasonable) object, like a palm tree or a duck or a wheel ... whatever. As long as the NIF meets requirements for the game, it will be rendered. The problem is that if the object bounds are not defined accurately in the plugin, then DynDOLOD will use the vanilla object bounds, to possibly make certain 'decisions' about billboard creation and LRs (for now ... maybe more in the future). So the only way to define the object bounds is to create a plugin for the mod, forwarding the vanilla records, and using the CK to recalc bounds. This is best practice in terms of DynDOLOD (and probably other contexts), correct?

You are actually (correctly) reading the OP linked from the guide (this is rare, so kudos), but you are trying to make sense of it without the full context of some of the technical 'basics' of how apps are configured to work together. That can get complex and is beyond scope. Here's the context for what you are ultimately doing (configuring xLODGen to run from MO): PS: Continue reading, but you don't need to set this up in real time as you read the OP. Finish reading that, and then continue on in the guide, which will explain how to set it up similarly to what that image^ is showing.

yes. 0.5 is fine. Basically, setting them all equal and < 1.0 normalizes without bias. I wanted to point you to the new CG/non-CG settings.

Yes, but there's new settings if you keep up with DynDOLOD 3. I explained it in the sticky for the CL-CG mod, but it's also in the DynDOLOD_SSE.ini and the DynDOLOD documentation. Regardless, you will always get some grass pop-in during transitions more/less depending on time of day, since even the modded game isn't perfect due to game limitations. Setting proper grass load distances via the INI as indicated in the Step SSE guide optimizes things too, but those videos you posted look pretty good in terms of grass LOD transitions.

Grass LOD can't really be compared. As long as the grass mod has grass properly defined in the plugin with object bounds, the LOD adopts the textures and meshes appropriately. If the full grass looks good, the LOD grass will look proportionately the same relative to full grass as any other grass mod. The variability lies in the grass color, ENB, weather, and if it is complex grass or not. This can all be optimized equally well for any grass mod LOD by adjusting TexGen settings, and DynDOLOD_SSE.ini settings specifically for each grass mod. All else being equal, if LOD for one grass mod looks better relative to full grass than some other grass mod, it's due to DynDOLOD not being optimized for the worse one.

Tagged for testing

I think this mod plays fine with the mandate, given those mandate-breaking features are disabled by default (or can be disabled via INI where not). Arguably, this mod is allowing something that Bethesda missed and is effectively an insurance policy for the user. Tagged as testing to be sure.