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.

[RainingTacco]

Would be great if the updating of the LOD system was overhauled/improved. Imagine if all files in load order were hashed let say a 32 or even 64 bit hash, and every run settings saved[dyndolod settings, maybe even load order], even with 2 million hash files, it would be a trivial amount of space taken. Then compare if the hashes were changed and if settings were changed in dyndolod[save the settings for every lod generation run]. Let say no hashes were changed ie. same files, but you've changed the grass lod density --> compare then run only grass lod update with just clicking update, no user thinking about anything. Let say a plugin changed -> run occlusion. Meshes were changed[you could use flags/bits to encode if its mesh/texture etc]--> execute lodgen, texture changed --> execute atlas. Basically something like Git lite being implemented. Just food for thought. Speaking of Dyndolod, is it planned to go open source any time in the future? That would allow someone to try to rewrite it, similarily how CS was eventually created with people who were tired of closed source nature of ENB. Right now when i change the grass lod density i run execute lodgen and it still is slow, and i still dont know if i should load the old dyndolod output and hit execute lodgen, or run the execute lodgen without output and then merge it with the old one. 

Edited Friday at 05:03 PM by RainingTacco

[sheson]

1 hour ago, RainingTacco said:

Right now when i change the grass lod density i run execute lodgen and it still is slow, and i still dont know if i should load the old dyndolod output and hit execute lodgen, or run the execute lodgen without output and then merge it with the old one. 

See https://dyndolod.info/Help/Grass-LOD#Updating and https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins.
For executing LODGen, which just generates new object LOD BTOs from distinct NIFs, any  existing BTOs are irrelevant.

Generating the millions of grass billboards into the hundreds BTOs files takes time. For me the total is 4 minutes for object, ultra 3D tree and grass LOD for vanilla Tamriel.

https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size
Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes. If the total file size for an object exceeds hundreds of MBs, consider creating an optimized LOD model.

Look for 3rd party "LOD" model that need optimizing. They more often then not are the cause for slow LOD generation and also having the worst impact on performance in game apart from grass LOD. Creating better LOD models is where to spend time on to improve things.

[Bushranger]

This might just be me confused but I seem to be unable to update DynDOLOD. I noticed a couple weeks ago it had updated with the changelog message at the bottom of the window so I downloaded 3.00 alpha 198, I deleted the /tools/DynDOLOD and then extracted the update to /tools/DynDOLOD. I then went through and edited /tools/DynDOLOD/Edit Scripts/DynDOLOD/DynDOLOD_SSE.ini and /tools/DynDOLOD/Edit Scripts/DynDOLOD/TexGen_SSE.ini before later using MO2 to activate them with not much attention to the top where it lists exactly what is running and the bottom where it lists changelog. I ran it a couple of times at the beginning of this week where I've posted here about it.

I also ran it again this morning after spending last night updating my mod list to try Spell Research and I noticed at the bottom that "A new version is available. Changelog." Only it's still DynDOLOD 3.0 Alpha 198 and what was most surprising was when I looked back it shows DynDOLOD 3.0 Alpha-197 x64 - Skyrim Special Edition (SSE) at the top of the window. I've spent the morning thinking I've done something wrong and tried to correct it by removing the tool connections from MO2 before closing it, following the update instructions and changing the /tools/DynDOLOD to /tools/DynDOLOD.old before installing it in a differently named folder and then connecting MO2 to those but it still shows as Alpha 197 and that A new version is available. I'm sorry if this is a lot but I do get confused easily, what have I missed?

[sheson]

19 minutes ago, Bushranger said:

This might just be me confused but I seem to be unable to update DynDOLOD. I noticed a couple weeks ago it had updated with the changelog message at the bottom of the window so I downloaded 3.00 alpha 198, I deleted the /tools/DynDOLOD and then extracted the update to /tools/DynDOLOD. I then went through and edited /tools/DynDOLOD/Edit Scripts/DynDOLOD/DynDOLOD_SSE.ini and /tools/DynDOLOD/Edit Scripts/DynDOLOD/TexGen_SSE.ini before later using MO2 to activate them with not much attention to the top where it lists exactly what is running and the bottom where it lists changelog. I ran it a couple of times at the beginning of this week where I've posted here about it.

I also ran it again this morning after spending last night updating my mod list to try Spell Research and I noticed at the bottom that "A new version is available. Changelog." Only it's still DynDOLOD 3.0 Alpha 198 and what was most surprising was when I looked back it shows DynDOLOD 3.0 Alpha-197 x64 - Skyrim Special Edition (SSE) at the top of the window. I've spent the morning thinking I've done something wrong and tried to correct it by removing the tool connections from MO2 before closing it, following the update instructions and changing the /tools/DynDOLOD to /tools/DynDOLOD.old before installing it in a differently named folder and then connecting MO2 to those but it still shows as Alpha 197 and that A new version is available. I'm sorry if this is a lot but I do get confused easily, what have I missed?

See https://stepmodifications.org/forum/topic/19903-dyndolod-300-alpha-198/page/720/#findComment-288627

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search

[z929669]

13 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.

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

Test logs