z929669

I think it's the Myrwatch patch that is causing the issue.

Again, it's not your DynDOLOD version. It's a configuration problem. Go through steps to ensure all of your config is in order. It's probably something small and seemingly insignificant. Check MO overwrite ... there are so many things that could be off from some random thing that was done since you upgraded DynDOLOD. Lots of things can prevent object LOD from rendering, so we are just stabbing in the dark at this point. Create a vanilla profile and run alpha 97. I'll bet it works fine.

Ahhh, now I understand the problem. I didn't realize the main menu was gone from that screen.

Agreed. @mooit Your missing LOD has nothing to do with Alpha 97. The same problem would exist with Alpha 95|96. You either have a load order issue, DynDOLOD plugins are not active, or configuration settings are not correct for rendering object LOD. As you already mentioned, you have terrain BTO files with the objects. They are not rendering in game due to a general configuration problem. perhaps it's related to the latest game update or some other random factor.

Looks like 'blank' trunk textures

Updated FOMOD instructions for latest update: Version 3.0 Improved mesh visuals with updated shader flags and emissive variables Forwarded changes from most mesh fix mods Added new glacier cubemap and optimized gradient textures Streamlined FOMOD options and eliminated redundant files to reduce bulk

OK, I will definitely try that in my next test. Unfortunately, the Skyrim update is in my way, so I will need to set up another MO profile for this testing (stripping out broken mods ... will take me some time, as I want to use the same grass cache for LOD). SKSE doesn't seem to be updated though. Thank you

OK, so I can see they are horizontal vectors (0 I think) in DynDOLOD_flat_4x2alt_lod.nif: Face normals are angled? .... but how do you show them in red as you have done in the BTO?

I was looking at the two planes and how they intersect at 90 degrees, but the planes are angled at about 15 degrees from the vertical. I don't know how to show the normal vecors as you have done.

OK, so it looks like the CG billboards are not perfect verticals but angled a bit up/down, and the normal vectors are quite variable. All I can say is that the normals image I posted demonstrates the difference in normals between LOD and full grass. Here's that file BTW if you want to try. Set EnablePrepass=true in enbseries.ini while using this FX: enbeffectprepass.fx

The Step guide (wiki) settings are specific to the Step mod list and will not necessarily be optimal for your mod list. DynDOLOD's defaults are based on optimization against vanilla (the 'standard'). This wouldn't cause missing LOD grass/trees though. I just wanted to clarify that the 'wiki' visual settings are not the vanilla standards shipping with the DynDOLOD configs. Make sure your grass cache is actually GID and not CGID, and ensure that you are ticking 'Ultra' for trees. Otherwise, you may be using traditional tree LOD with fTreeLoadDistance=0 in skyrimPrefs INI EDIT: but your screens show that you are not even generating mountain LOD, so you should check the reasons sheson stated and possibly your DynDOLOD output (plugins enabled, asset conflicts)

Thanks for sharing. These results are similar to testing screens Enzombie posted on that ENB discussion. Vanilla complex grass LOD seems to have less of a difference with full at varying ToD (in the otherwise vanilla game) than Cathedral grasses in Step. It's still most contrasting at midday, but it's only very subtle. With CL grasses under Cathedral Weathers, there is more variation between LOD/full complex grass. The sweet spot is still there, but just a bit less forgiving at midday and/or dawn/dusk, depending on weather and which you are optimizing (or the happy medium between the two). Ultimately, the difference seems to be due to the vectors of the normal faces of LOD grass billboard models being tangent to sky/ground, whereas the normal faces of loaded grass are at non-perpendicular angles to sky/ground (something between 45-90 degrees): Given that grass LOD is static and lighting effects are more limited, there is probably no way to compensate outside of randomly varying the billboard normal-face angles relative to the horizontal. I have it matching pretty well in my instance, but vanilla seems more forgiving.

Are you using instances then? (#1) This is the proper way to manage multiple games other than using separate portable installs of MO. You can use profiles (#2) to manage different mod lists under the same game:

I am not familiar with this context, but in most situations, I think 'threads' are usually double the cores, so a quad core has 8 threads. But this situation may be defining cores? I see only "logical processors" mentioned in the description though.

Yes, do select that. We never updated the mod instructions to reflect I guess. Updated now. Thanks for reporting by DY ... yes, this is correct, but instructions ward off questions this way

OK, so it still seems like ENB could target/modify/inform/query the default LOD shader in the BTO, so I don't understand his comment about "math is regular as for any object". Full grass and LOD grass are different objects. PS: In other words, it seems to me like you made it easy for him, but IDK. PSS: I assume you tested "Vanilla Complex Grass for ENB" mod using default latest 0.475 ENB without modification?

Normal being used as well, got it. I assumed as much but want to be careful to state what I don't know for certain. (sidebar: then the alpha CG pixel indicator should be present. Coupled with the fact that all grass LOD on a given BTO share shader properties --and you have total control of the BTO, then ENB should be able to target with CG-related algorithm ... not sure why Boris is saying otherwise). Default config settings all makes sense, since the config is based on vanilla tested outcomes. We are using an algorithm that works for the Step SSE build (Cathedral weathers, landscapes, and Step ENB). Setting all at a single value for CG and non-CG grass just makes instructions and support simpler, and it should work similarly for those not using our exact build. I can add a note about this though to clarify for pure vanilla CG users.

I have seen myself that TexGen takes the grass texture atlas and splits it and uses the diffuse. I think it also uses the normal, but I would need to look at the BTO to say for sure. That mod page description should be updated. DynDOLOD supported CG starting months ago or more soon after CG was released for ENB, but now it's even better. Yes, we are now recommending 0.5 to simplify end-user ability to modify each color up/down for any particular reason. The important thing is that the values are normalized (all equal) so that they introduce no bias to the color outcome. In so doing, color bias in the outcome can be more easily traced to the source (usually ENB) and potentially corrected there if it's not desired. Setting to 0.5 just means that we will proportionately increase Direct/Ambient brightness in TexGen. Since DynDOLOD alpha 96 changed GC grass LOD support, all of this is a bit different, and the old settings will not really work as consistently. Z-fighting is not something I have witnessed in grass. This is usually mountains or trees, since they are large and can be seen at distance. Use Level0 to help with those (we set mountain to be Level0/Level0/Level1). Your ENB should be whatever it is, but I have evened out our day/night CG settings in ENB since Alpha 96. You will need to experiment with your ENB if necessary. CG increases the time of TexGen marginally, but I haven't noticed any noticeable diff in DynDOLOD. Always clean save between loading of different DynDOLOD outputs (unless they have the same plugin bits ... i.e., if you change TexGen settings but not the mod list) Those paths have existed for me since April, but that's a question for @sheson

This sounds like a Vortex issue or related. Try naming as something more unique and be certain that the file is different than DynDOLOD output (you may have packaged up the same outputs into different file names, and Vortex noted the CRC hashes matched).

So first of all, for SSE, you should have installed DynDOLOD Resources Alpha-28 as a mod fairly early in your installer list (this should be overridden by most conflicting mods). The DynDOLOD app itself is installed (extracted) in any directory location outside of Vortex, preferably anywhere on your drives outside of Win UAC control (e.g., C:\DynDOLOD). Vortex is then configured to launch first the TexGen and then DynDOLOD and EXEs as Vortex-hosted applications. When this is configured, Vortex should be using your mod List (including DynDOLOD Resources) to construct the respective outputs in C:\DynDOLOD\TexGen_Output and C:\DynDOLOD\DynDOLOD_Output. The contents of these directories should be installed as mods in Vortex as the very last mods in your install priority (DynDOLOD Output mod overrides TexGen Output mod, and TexGen Output is required for use by DynDOLOD to generate the DynDOLOD Output). I'm not sure exactly how Vortex organizes the files internally, but the application should list those mods in that priority. If you get the DynDOLOD Sucessfully Initialized message in game, then you have presumably done this all correctly at least in terms of providing the right mods. We explain the gist of it all in our SSE guide linked in the top nav.

When the run completes, I am usually at the keyboard waiting for it. I try not to maximize the LODGen CMD windows or have other windows open. The save/exit dialog appears over the xEdit processing window. 50-75% of the time, I simply click Check Log or Save/Exit without issue, but the rest of the time, the dialog is not fully rendered, which indicates to me that the process governing that is about to close disgracefully (and does). I will test default windows theme to see if it helps. I just completed successful runs of TexGen and DynDOLOD 97, so here's those logs.

TexGen ran fine this time. DynDOLODx64.exe had the 0xc000041d error though. Running non default Windows theme under Win 11 this time. logs (no bug report produced)

Just want to report an ongoing issue with all of the alpha versions since like alpha 33. I haven't reported these for a while, since we got nowhere with a similar but worse issue about a year ago (it was mysteriously resolved for me with a subsequent alpha update). I will try again. This happens at the very end of running either TexGen or DynDOLOD about 25% of the time for me. The processing completes and the exit/view log dialog appears in a partially-rendered state before the program quits disgracefully ... NO logs or bug report is ever created, since there is no hand-off to the process that creates the logs ... or in the case of DynDOLOD: saves the plugins. With TexGen, this is not an issue, since I run against the same mod list pretty much constantly in testing, and I know my output bit sizes, which are always consistent, given the nearly identical LO each run. I just use the TexGen output in such cases and move on to DynDOLOD without issue. With DynDOLOD, it's quite frustrating, as it's a waste of 15-50 minutes of processing, depending. Reason being because the program disgracefully halts without generating the plugins (I could probably reuse those from other runs, but I don't ... they are usually the same exact bits). Anyway, the only clue is in the Win event log, and it's always the same for either program: Faulting application name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x63207073 Faulting module name: KERNELBASE.dll, version: 10.0.22000.918, time stamp: 0xb42fa627 Exception code: 0xc000041d Fault offset: 0x000000000004474c Faulting process id: 0x2604c Faulting application start time: 0x01d8c7dd47b3dae2 Faulting application path: C:\Modding\Tools\DynDOLOD\TexGenx64.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Info on the error: https://github.com/dynamorio/drmemory/issues/1355

ENB-CG won't affect grass cache, since they are just textures. It's the CL plugin that governs grass placement. Once you generate the cache in 1.5.97, you don't need to load that instance. You can just move it over to 1.6.xxx and generate DynDOLOD.

Refer to my previous post for context. Testing the aspens again using the latest alpha 97 ... The first screen corresponds to test case #4 in contextual link above (this is what is configured in the AA DynDOLOD Add-On mod (performance, autumnal). The second screen is using the same models exactly but referencing the original AA diffuse (test case #1 in the contextual link above) rather than the special version I created from the 256 mip of the original (saved this without mips). UPDATE: since I did not set "UseMipMaps" in the name strings of the crown BsTriShapes of the LOD models, this is effectively DynDOLOD mipmapping of the original AA crown textures. The third screen is based on the same setup as the second screen, but the "UseMipMaps" keyword was added to the BsTriShape name strings of all LOD models: Note that using the native AA texture mipmaps is much too thin, so it's the correct direction, but too far. The solution would either be to lower the NiAlphaProperty to something like 64, or continue using the custom branch texture as test case #4 described in the contextual link above. The "UseMipMaps" feature may still be useful in some current/future situations, so thatnks for that. Logs corresponding to the third image: https://mega.nz/file/nMlCRRrb#dPQ4BXCqf_NAiwEUzFdpehj7PyAubK1dUMyFjrevGoo