DynDOLOD 3.00 Alpha 198

[z929669]

I'm reporting my findings in resolving a long-standing EVT issue where the tips of pine crowns can be much darker than the lower branches, depending on the textures used. I have determined that the primary cause is alpha bleed, and the more vertical normal faces of the top branches are only a minor contributing factor at most.

For those that are not familiar, alpha bleed occurs when lower-level mipmaps incorporate pixels adjacent to the alpha border when rendering a texture with alpha transparency (most notably, foliage textures). If said pixels are black or a very different color than the unmasked portion of the alpha channel (the non-transparent foliage), they can pollute the rendered textures at higher mipmap levels, causing mild to drastic change in color of the rendered textures. The following example shows a spruce leaf on a black background with the bright alpha border outlining the subject. In this case, the background is black and would not be seen, since it is masked by the alpha, but that can change at lower resolutions (higher mipmap levels):

The alpha-bleed issue is only slightly evident in the loaded, full crowns but is far more evident in the DynDOLOD atlas textures created during DynDOLOD processing. I think it's because the DynDOLOD-generated atlas for some foliage has a black background. Where the background is not black but rather something closer to the unmasked pixels, the problem is resolved. See the following from DynDOLOD_Tamriel_Alpha.dds (I placed a blue box around the subjects of interest):

DynDOLOD's default atlas   DynDOLOD's 'usemipmaps' atlas

When the LOD crown shape name includes the `usemipmaps` keyword, DynDOLOD uses the mipmaps of the original texture (with like-colored background if present) rather than remaking them (against a black background). In my testing with EVT and this particular set of branch textures, the fix is to apply the `usemipmaps` keyword to the LOD shape names of the crowns. I should also mention that using `noatlas` keyword also resolves the issue, but sheson mentions that this can impact performance (I didn't have a performance impact though ...more on that later). The `sherenormals` keyword also resolves, but causes the LOD Ultra trees to be much too light, due to the radial normal vectors.

I tested with remade 8K atlases of 'treepineforestbranchcomp*.dds' variants, which DO have a black background, so I hastily remade variants having backgrounds that match the subjects (using Flaming Pear > SolidifyC algorithm) and created mipmaps using the Kaiser method with either 112 or 128 alpha scaling (alpha-to-coverage), because the crown meshes use `NiAlphaProperty` at 112 rather than 128 (DynDOLOD only uses 128 in LOD).

Compares

1. default-modified-8k-112 - DEMONSTRATES THE PROBLEM - Default DynDOLOD behavior (DynDOLOD uses its regenerated texture atlas + mipmaps for LOD), modified texture background, 112 mipmap alpha-to-coverage threshold - only LOD trees have the dark tops, presumably because the regenerated DynDOLOD atlas creates a black background for these branches.
2. noatlas-modified-8k-112 - suboptimal fix - `noatlas` shape name (DynDOLOD uses the native full texture atlas + mipmaps for LOD rather than its own regenerated atlas), modified texture background, 112 mipmap alpha-to-coverage threshold
3. usemipmaps-modified-8k-112 - better fix - `usemipmaps` shape name (DynDOLOD uses the native texture mipmaps for its atlas), modified texture background, 112 mipmap alpha-to-coverage threshold
4. usemipmaps-modified-8k-128 - better fix, better distant foliage - `usemipmaps` shape name (DynDOLOD uses the native texture mipmaps for its atlas), modified texture background, 128 mipmap alpha-to-coverage threshold
5. usemipmaps-original-8k-? - suboptimal fix - `usemipmaps` shape name (DynDOLOD uses the native texture mipmaps for its atlas), original black texture background, mipmap alpha-to-coverage threshold unknown (presumably 128) - the pine branches are too dark, presumably due to the black background of the original textures

1 default-modified-8k-112 2 noatlas-modified-8k-112 3 usemipmaps-modified-8k-112 4 usemipmaps-modified-8k-128 5 usemipmaps-original-8k-?

1 default-modified-8k-112 2 noatlas-modified-8k-112 3 usemipmaps-modified-8k-112 4 usemipmaps-modified-8k-128 5 usemipmaps-original-8k-?

1 default-modified-8k-112 2 noatlas-modified-8k-112 3 usemipmaps-modified-8k-112 4 usemipmaps-modified-8k-128 5 usemipmaps-original-8k-?

1 default-modified-8k-112 2 noatlas-modified-8k-112 3 usemipmaps-modified-8k-112 4 usemipmaps-modified-8k-128 5 usemipmaps-original-8k-?

All logs and data for each of the 5 tests

Ultimately, it seems like the issue of alpha bleed could be resolved by using a color-matched background instead of black. This is what DynDOLOD does for many foliage 'miniatlases' in DynDOLOD_Tamriel_Alpha.dds.

[sheson]

7 hours ago, z929669 said:

I'm reporting my findings in resolving a long-standing EVT issue where the tips of pine crowns can be much darker than the lower branches, depending on the textures used. I have determined that the primary cause is alpha bleed, and the more vertical normal faces of the top branches are only a minor contributing factor at most.

For those that are not familiar, alpha bleed occurs when lower-level mipmaps incorporate pixels adjacent to the alpha border when rendering a texture with alpha transparency (most notably, foliage textures). If said pixels are black or a very different color than the unmasked portion of the alpha channel (the non-transparent foliage), they can pollute the rendered textures at higher mipmap levels, causing mild to drastic change in color of the rendered textures. The following example shows a spruce leaf on a black background with the bright alpha border outlining the subject. In this case, the background is black and would not be seen, since it is masked by the alpha, but that can change at lower resolutions (higher mipmap levels):

The alpha-bleed issue is only slightly evident in the loaded, full crowns but is far more evident in the DynDOLOD atlas textures created during DynDOLOD processing. I think it's because the DynDOLOD-generated atlas for some foliage has a black background. Where the background is not black but rather something closer to the unmasked pixels, the problem is resolved. See the following from DynDOLOD_Tamriel_Alpha.dds (I placed a blue box around the subjects of interest):

DynDOLOD's default atlas   DynDOLOD's 'usemipmaps' atlas

When the LOD crown shape name includes the `usemipmaps` keyword, DynDOLOD uses the mipmaps of the original texture (with like-colored background if present) rather than remaking them (against a black background). In my testing with EVT and this particular set of branch textures, the fix is to apply the `usemipmaps` keyword to the LOD shape names of the crowns. I should also mention that using `noatlas` keyword also resolves the issue, but sheson mentions that this can impact performance (I didn't have a performance impact though ...more on that later). The `sherenormals` keyword also resolves, but causes the LOD Ultra trees to be much too light, due to the radial normal vectors.

I tested with remade 8K atlases of 'treepineforestbranchcomp*.dds' variants, which DO have a black background, so I hastily remade variants having backgrounds that match the subjects (using Flaming Pear > SolidifyC algorithm) and created mipmaps using the Kaiser method with either 112 or 128 alpha scaling (alpha-to-coverage), because the crown meshes use `NiAlphaProperty` at 112 rather than 128 (DynDOLOD only uses 128 in LOD).

Compares

1. default-modified-8k-112 - DEMONSTRATES THE PROBLEM - Default DynDOLOD behavior (DynDOLOD uses its regenerated texture atlas + mipmaps for LOD), modified texture background, 112 mipmap alpha-to-coverage threshold - only LOD trees have the dark tops, presumably because the regenerated DynDOLOD atlas creates a black background for these branches.

All logs and data for each of the 5 tests

Ultimately, it seems like the issue of alpha bleed could be resolved by using a color-matched background instead of black. This is what DynDOLOD does for many foliage 'miniatlases' in DynDOLOD_Tamriel_Alpha.dds.

It  seems you might be reporting a problem with the default automatic average color function for textures with transparent parts being added to the object LOD atlas.

In case the average color is not applied you can try setting ObjectLODForceAverageColor=1 in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Provide a LOD model and its textures exhibiting this problem.

Textures should not have black transparent parts to begin with, though. This also means they shouldn't use DXT1 compression.

It is the game which is hardcoded to use an alpha threshold of 128 for BTOs.

[z929669]

3 hours ago, sheson said:

It  seems you might be reporting a problem with the default automatic average color function for textures with transparent parts being added to the object LOD atlas.

In case the average color is not applied you can try setting ObjectLODForceAverageColor=1 in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Provide a LOD model and its textures exhibiting this problem.

Textures should not have black transparent parts to begin with, though. This also means they shouldn't use DXT1 compression.

It is the game which is hardcoded to use an alpha threshold of 128 for BTOs.

Yes, exactly right. Apologies for not stating the question more clearly in all that. I will test using `ObjectLODForceAverageColor=1` and let you know.

[z929669]

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

[sheson]

7 hours ago, z929669 said:

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

I now have a texture, I am still missing a LOD model exhibiting this problem.

If you want to solve this problem with a proper texture, then update the textures from the linked mod with image editing tools.

[captainlei1993]

On 1/6/2026 at 1:35 PM, ikonomov said:

I am sharing a combination of settings that I have found to work very well for vanilla grass when used with Community Shaders.  The area around Whiterun at sunset has been particularly challenging to get the full and LOD grass to transition smoothly.  I thought somebody might find this useful.

DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI
ForceComplexGrass=2

TexGen HD Grass billboards
Direct 0, Ambient 100, Smoothness 0

DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
ComplexGrassBillboard=5
ComplexGrassBacklightMask=100

Community Shaders/Grass Lighting (needs the separate mod for the extra settings)
SSS Amount: 0.350
Brightness: 0.750

Seems pretty nice. What complex grass texture for vanilla grass do you use?

[z929669]

4 hours ago, sheson said:

I now have a texture, I am still missing a LOD model exhibiting this problem.

If you want to solve this problem with a proper texture, then update the textures from the linked mod with image editing tools.

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.

[z929669]

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.

[sheson]

23 hours ago, z929669 said:

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.

I installed Enhanced Vanilla Trees SE-Basic 2.2.2 with default options and then Pine Branches Redone 8k 4.0 which have black backgrounds.

My DynDOLOD_SSE_Object_Report.txt matches yours from the default-modified-8k-Logs.7z for every tree using textures\landscape\trees\treepineforestbranchcomp.dds, so we have the same full and LOD models and texture paths.
I have a different CRC32 for treepineforestbranchcomp.dds, since I have the one from the mod with black background and not your modified versions you used back then.

My and your debug log from default-modified-8k-Logs.7z both show two lines like this while the object LOD atlas is generated for Tamriel:
[PrepareImageColorFix] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds force False>
which means that the black background is being replaced. There are two lines because one version is for the alpha threshold 90 and the other one for 112.

As expected, the background color for those branch textures in the object LOD atlas texture are not black anymore since they got replaced by the average color:

There is nothing in your debug log that indicates why it would be still black instead.

When I run the same setup with your 16k versions  overwriting the ones from Pine Branches Redone, their proper background is kept as it is supposed to:

Get the latest test version from https://dyndolod.info/Downloads/Test-Versions and run the default setup with textures that have black backgrounds and upload new DynDOLOD log and debug log. Those log lines for PrepareImageColorFix will now show few numbers I am interested in.

[z929669]

2 hours ago, sheson said:

I installed Enhanced Vanilla Trees SE-Basic 2.2.2 with default options and then Pine Branches Redone 8k 4.0 which have black backgrounds.

My DynDOLOD_SSE_Object_Report.txt matches yours from the default-modified-8k-Logs.7z for every tree using textures\landscape\trees\treepineforestbranchcomp.dds, so we have the same full and LOD models and texture paths.
I have a different CRC32 for treepineforestbranchcomp.dds, since I have the one from the mod with black background and not your modified versions you used back then.

My and your debug log from default-modified-8k-Logs.7z both show two lines like this while the object LOD atlas is generated for Tamriel:
[PrepareImageColorFix] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds force False>
which means that the black background is being replaced. There are two lines because one version is for the alpha threshold 90 and the other one for 112.

As expected, the background color for those branch textures in the object LOD atlas texture are not black anymore since they got replaced by the average color:

There is nothing in your debug log that indicates why it would be still black instead.

When I run the same setup with your 16k versions  overwriting the ones from Pine Branches Redone, their proper background is kept as it is supposed to:

Get the latest test version from https://dyndolod.info/Downloads/Test-Versions and run the default setup with textures that have black backgrounds and upload new DynDOLOD log and debug log. Those log lines for PrepareImageColorFix will now show few numbers I am interested in.

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