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.