z929669

I'd like to know this as well. I don't understand why NifSkope doesn't have axis values in the UV editor. Putting it in vertex mode and selecting a number of vertices shows that everything I select is in 0-1 range, so I think the light gray box is 0-1 (or -1 to +1 in Cartesian space) ... so if that's true, then the dark gray must be 0-3 (or -3 to +3)??

You can test in game using Shift+Enter to adjust settings on right side (current weather) to see the impact and limits of each setting. I use AMD, so no idea about NVIDIA driversoft settings. You should be able to set by game though.

I used NVIDIA Texture Tools Exporter and just opened and saved with alpha mipmap coverage threshold box checked at default threshold of 127. All other settings default (but saved using 'normal' method instead of 'fastest'). I'm guessing you could alternatively use Texconv -keepcoverage number as sheson said, but I don't know what 'number' represents. Maybe increasing NiAlphaProperty to 128 on the branch node would resolve completely, but not sure without testing.

You could also try this version of one of the diffuse used. I just saved at alpha mipmap coverage threshold of default 127. This is probably close to what DynDOLOD uses, I assume.atlas_pine.7z PS: I should have mentioned that you could use the texture on the original version of pine01 I think without "UseMipMaps" removed.

While sheson is away ... This is what I would do. Try regenerating DynDOLOD using this version of the LODs you sent. This removes the "UseMipMaps" string from the branch BsTriShape name, which --as I learned just a few posts back-- is what prevents DynDOLOD from generating the branch texture mipmaps for the LOD version as usual. It will instead use the mips in the texture. It could be that the texture mipmaps are not done properly (I looked at them, and they get very thin) ... if that's the case, you should notice that the loaded full trees in the farthest distance before LOD begins look thinner than the close ones. It's worth a try. If it looks better, the mod author should be told to fix the mips or remove the string. These LODs are also not hybrids for some reason, so unnecessarily complex for LOD. Branch UVs look fine to me, and trunk UV doesn't matter (no alpha transparency to worry about). The NiAlphaProperty is quite low (40), but I don't think it matters much. But it would matter if the MA used a texture alpha threshold to match it (not sure how to check that or if that info is in the texture).

Testing with these changes for Alpha 119. Default is using ComplexGrassBillboard=4, ComplexGrassBacklightMask=0 L to R: Default >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=50 This doesn't seem right. First images show as expected, but I did not expect that these changes would affect loaded grass, so I'm verifying ... wait one. I confirmed that EVLaS has no impact. No shadow is cast my the distant mountain. It should creep along towards the PC as the sun is occluded. Any ideas? Terrain underside not working maybe? Logs Disregard previous compare. I was lazy and loaded up the game on my save without clean saving first. Using a clean save or new game resolved EVLaS interaction: L to R: Default >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=50 >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=25 Better, but I think ComplexGrassBacklightMask=25 may be the best trade-off

Tested latest features in Alpha 119 using defaults for grass (backlighting flag unset using external billboard). Following are screen compares with my previous under 118: Left to right: Alpha 118 >> Alpha 119 So this looks great when the sun is down. While the sun still shows over the mountain though, matching is a bit worse. Should I play with ComplexGrassBacklightMask then? Keep using ComplexGrassBillboard=4 or switch to 5?

That's the first thing I tried ... not seeing those settings in the 119 DynDOLOD_SSE.ini My fault. I made a mistake in updating my upgrade INI

@sheson Question about new features in latest update: Is the documentation on these features pending?

So if your BethINI settings are all per recommendations (including iMaxParticles, Ambient Occlusion, etc.), then you can try updating to the latest ENB binary. I do think that ENB torch light should be brighter, so I will note that in the next PP Patch update. These things can also be influenced by your driversoft graphics settings, so you might want to look at those just in case. Otherwise, things like monitor and graphics hardware can vary a bit. To increase this lighting with ENB, there's many options, but I would play with increasing: [ENVIRONMENT] - AmbientLightingIntensity* and [SKYLIGHTING] values for exterior (I would not increase these much, as they are powerful and can affect many things) Settings exist for interiors day/night and exteriors at several times. These also must be edited under ..\enbseries\Weather\ for EACH weather. Don't change anything in enbseries.ini.

Are you using all mods and patches in 2.2.0 as instructed without any additional mods? These screenshots are fairly typical of expectations. The vanilla lighting without ENB is far too bright in those shots, and with ENB is a tad bit too dark. Have you tried adjusting in-game brightness from options menu?

Why use BDS and SoS? You need to pick one or the other, and disable Wintersun - Faiths of Skyrim. Do that and see if the issue is resolved.

What is this command? How can we invoke/test? I'm asking in relation to different trees/textures.

Strange. I just checked, and they are at the end of the file and have been for days: Maybe because I quit DynDOLOD ... in which case, I'm not sure why the bugreport.txt was generated (there was no error in the logs)

Finally got a bug report with these added debug settings. Note that I cancelled this process myself by gracefully aborting DynDOLOD when I noticed I had not killed all AMD Adrenaline processes beforehand, which makes TexGen/DynDOLOD take forever when active. Perhaps we'll get some insights as to what in the hell AMD software is doing to add this unnecessary overhead. I personally think it's some sort of AMD texture-mediation algorithm due to Adrenaline not understanding that DynDOLOD is not a game.

That was it. file out of sync, due to multiple generations combined here manually. The trees of Veydogolt just have too many triangles on average and the LODs need to be decimated a BTO of 0.5 Gb is an order of magnitude bigger than it should be. Some of these hybrids have crowns with 40,000 triangles, so they need to be decimated. Thanks

On game launch with the the output generated by this run (logs above), I am getting an in-game message "can not find master in DynDOLOD_None" ... I searched your doc and didn't find anything on this issue. DynDOLOD is 'inactive', so I assume dynamic LOD won't work, but I have static LOD. Testing on a new game.

Could this be useful for grass LOD compatibility as well? Specifically thinking of ENB complex grass LOD compatibility.

I don't run Open Cities, so I don't know offhand. The DynDOLOD documentation has details on how to generate for OC.

TrueDirectionalMovement was my next contender. I'm pretty sure you will just need to patch them (or fix the offender)

Yeah, I'm working with him on that ... too many irons!

Looks like a mesh issue in Better Third Person Selection. Disable that mod to confirm. Then you will need to report it to the MA.

Added those params to the INI, and of course, I got no errors this time for the first time after like 10 attempts. It took 6.5 hours for LODGen to finish so DynDOLOD could create the plugins, and the output is massive (39+ Gb). I attribute this to the diversity and complexity of the Veydogolt Trees and corresponding LODs. This will be address but is beside the point Here's the logs, but probably don't reveal much: Logs Now I will work on invoking the issue by reattempting. The failure happens early on in the process when it does happen, so I will abort and keep trying until I get a useful bugreport. EDIT: To verify my config and environment, I had already tested on my mod list without any of the Veydogolt stuff using the most recent Alpha and non-NG DLL, and it ran just fine in about 15-20 minutes. So the problem runs are due to Veydogolt. Note that there are several normals named in non-standard fashion like *_4n.dds ... DynDOLOD issues these warnings, but I'm pretty sure they are benign, but IDK. EDIT2: I'm unable to reproduce the bug report. I have had three non-errors (just aborted once LODGen process began, as the error happens in initial creation of Tamriel *_glow.dds. I've had a couple of ungraceful closing of DynDOLOD (the window just disappears without bugreport). I will keep those params in the INI though and report back when I get a bug report.

This mod is not in our guide, so it's not of interest in this topic

Where are you in the guide? Per the instructions, do a smoke test after 02-Extenders, but do not test the game until most other mods are installed per instructions. If you only have half the mod list installed, things will not work properly. If you follow along with the guide, all instructions are provided.