z929669

sheson copied the setting to the GUI recently, but it's still in the INI, so you must not have unfolded DynDOLOD instructions:

Gotcha. Here's Test 1 and Test 2.

Moved to DynDOLOD support. Please post your DynDOLOD_SSE_log.txt and DynDOLOD_SSE_Debug_log.txt for qualified answers.

Using the latest Test Versions (Jan 27), no *.dds were generated in the output for test 1. I will pause here until you affirm before continuing.

To clarify, you want me to try UseMipmaps=0 in test 1 and then try GLAlphaCoverage=0 in test 2. For test 2, do you want UseMipmaps=0 commented or enabled?

Here's the results from test version dated 1/26/2026 13:12

It was handed of to leostenavo, but it's still the same. I updated the link in the OP and added some instruction.

Just making sure you noticed my previous post, since several others came in right after I posted this.

Alpha remains black on the atlas texture, but here's the relevant output/logs.

Here's the results with logs included just in case.

I added CPUMipMaps=1 and used default ObjectLODAlphaDiffuseFormat=225. The backgrounds of all textures are now using average color instead of black in DynDOLOD_Tamriel_Alpha.dds.

LODGen_SSE_ObjectAtlasMap_Tamriel.7z

You must be in the southern hemisphere. It's below zero for me. I don't get those warnings from RWT, so post in DynDOLOD support with logs for answers.

Here's those logs + alpha.

It shouldn't take any longer than normal for you, but you could try the test version of DynDOLOD.

I will generate the new test momentarily.

Here's the file. It still has the black alpha for the branches in question. I did use the unmodified 8k version with black backgrounds. You will notice that this also is an issue with aspen branch birch03_c.dds That one is from Aspens Ablaze 2.39

I'm still narrowing it down, but these are all in the lineup for testing:

I ran without using any shape names. ObjectLODForceAverageColor was default `0`. Test logs

Thanks. I will run this and share the logs after work in about 14 hours from now and report back.

I remade the branch textures from source 16k PNG. I think the alpha is optimal, and I solidified the background, saving at 127 alpha-to-coverage. I'm reusing the 8K normals for now. The full trees look great and nave no artifacts at distance. Foliage is full and same color for all loaded pines near or far. If I generate DynDOLOD without adding any shape names (the unaltered LOD models I linked previously), DynDOLOD still fails to generate an color-averaged background on the atlas, which results in the severely darkened pine tops in LOD only, due to alpha bleed. If I generate using `usemipmaps` shape name, DynDOLOD does reuse the existing mip levels of my textures, because the backgrounds are solidified, as expected in DynDOLOD_Tamriel_Alpha.dds. However, now the tops are a bit too light in LOD only, so alpha bleed is still occurring but with the solidified background, which must be a bit lighter on average. The problem is that if I refine the alpha further, tightening it around all the wispy pine needles, the alpha would be too thin in loaded branches and fade at distance. My other option is to darken the background just a bit. Either way, the main issue is that DynDOLOD still creates mipmaps with black background, so fixing this issue would resolve the root cause of the dark tops without the need to add shape names to the LOD, which is obviously suboptimal. This would allow proper control using the texture alone. I will try using TreeLODDiffuseFormat=226 in DynDOLOD_SSE.ini, but I don't want to spend time on redundant tasks if there is a chance you can reproduce and resolve the black background atlas issue.

Sorry. Have a look at SRG_treepineforestdead02_E86227DEpassthru_lod or SRG_treepineforestdead05_E7AB3AFApassthru_lod for the default LOD meshes of this download. The textures I linked (I used 8k) have a black background, so I just want to determine if DynDOLOD should be altering that black to the average in it's atlas. I am reworking the same textures from 16k source now, but it's taking a while to get it right for all 6.

Setting ObjectLODForceAverageColor to `1` (default `0`) didn't change the background of several branch textures. The debug log reports `true` for `ObjectLODForceAverageColor`. The backgrounds remain black for some reason. Side question: Is it possible to surface a config setting for some of the shape-name triggers? ...to override specific behaviors for specific targets similar to how mesh rules do it? Obviously, I'd rather solve this with a proper texture and alpha than rely on a change to the LOD meshes. I just want to prove that a proper color-averaged background will resolve the dark tops issue in LOD. I added DynDOLOD_Tamriel_Alpha.dds generated from this run to the logs linked following. I tested with the 8k rendition of these branch textures --OOTB, no changes. Logs

Try TexGen Ambient = 100+ for HD grass and ComplexGrassBacklightMask to a value more like 25. The left side remaining darker could be due to sun position, since you are using Sky Sync in CS. We don't know the ToD for your screenshot.

That's the mod I've heard works best, so I will maybe add that as an optional for the minority.