Optimizing Texture Alpha Threshold

[Mousetick]

Recap of essential info:

• DynDOLOD 3a148 / Resources SE 3a45
• Vanilla tree meshes with Pine Branches Redone texture replacer
• Level0 at LOD Level 4
• DynDOLOD Resources SE's 3D tree LOD models for vanilla trees
• Edited to add UseMipMaps to crown nodes
• In the process of adjusting NiAlphaProperty Threshold to make LODs thinner

Now that the atlas textures are using the full texture mipmaps, I'm running into transparency/loss of details issues at smaller resolutions.

Look at the trees near the house in the center of the pictures below. Notice there is no difference between 112 and 127, and at 128 the LOD is very very close to the full model, which is fantastic.

LOD Alpha Threshold 112 > 127 > 128 > Full model

However notice the trees further in the distance to the right of the house have been severely "shaved" at Alpha threshold 128. It gets worse with smaller mipmaps, looking at the trees far away at the foot of the mountains:

It would seem that the full texture's mipmaps were not created with alpha-to-coverage, or they are, but with some kind of cutoff point for alpha around 127.

Based on the following shots, does it look to you like the mipmaps have alpha-to-coverage?

I see on Microsoft's Texconv page that the -keepcoverage option takes an "alpha test reference value". If the mipmaps of the full texture were generated with an "alpha test reference value" of 0.5, could this explain the observed behavior, i.e. no change between 112 and 127, and then "shaving" at 128?

What value does DynDOLOD use when it generates the atlas mipmaps (i.e. when not using UseMipMaps)?

Thanks in advance for your input.

[sheson]

2 hours ago, Mousetick said:

Recap of essential info:

• DynDOLOD 3a148 / Resources SE 3a45
• Vanilla tree meshes with Pine Branches Redone texture replacer
• Level0 at LOD Level 4
• DynDOLOD Resources SE's 3D tree LOD models for vanilla trees
• Edited to add UseMipMaps to crown nodes
• In the process of adjusting NiAlphaProperty Threshold to make LODs thinner

Now that the atlas textures are using the full texture mipmaps, I'm running into transparency/loss of details issues at smaller resolutions.

Look at the trees near the house in the center of the pictures below. Notice there is no difference between 112 and 127, and at 128 the LOD is very very close to the full model, which is fantastic.

LOD Alpha Threshold 112 > 127 > 128 > Full model

However notice the trees further in the distance to the right of the house have been severely "shaved" at Alpha threshold 128. It gets worse with smaller mipmaps, looking at the trees far away at the foot of the mountains:

It would seem that the full texture's mipmaps were not created with alpha-to-coverage, or they are, but with some kind of cutoff point for alpha around 127.

Based on the following shots, does it look to you like the mipmaps have alpha-to-coverage?

I see on Microsoft's Texconv page that the -keepcoverage option takes an "alpha test reference value". If the mipmaps of the full texture were generated with an "alpha test reference value" of 0.5, could this explain the observed behavior, i.e. no change between 112 and 127, and then "shaving" at 128?

What value does DynDOLOD use when it generates the atlas mipmaps (i.e. when not using UseMipMaps)?

Thanks in advance for your input.

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are.

Textures/mipmaps fading into full transparency typically means the mipmaps were not generated with any alpha-to-coverage.

If you instructed DynDOLOD to use the mipmaps of the texture, the texture is used as is. If the threshold is the default 128, then there also is no threshold adjustment done by DynDOLOD.

DynDOLOD uses its own algorithm to adjust alpha. It is based on the principle that each mipmap is 1/4 of the one before it. Texconv uses a different method.

That was programmed before xLODGen/DynDOLOD needed to use Texconv because of BC5/6/7 compression - in fact I believe Texconv didn't have alpha-to-coverage function when we started using it.
I tested it a bit but never achieved better results that would have warranted going through external command line program for each texture added to the atlas.

I would expect a texture artist knows what programs and settings achieve the desired/best results.

[Mousetick]

26 minutes ago, sheson said:

Read the first post and or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to provide useful screenshots with more informative console.

Here are the full logs if you wish to look at them: https://drive.google.com/file/d/1ZNmpBzlHU1rrC1c6wjzUTRdPlMxaG-Qj/view

There isn't much to show in the console when looking at LODs, but here are the console shots of the tree full models that were discussed in previous post:

29 minutes ago, sheson said:

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are.

As discussed and shown previously, the mipmaps generated by DynDOLOD look very different than the full texture mipmaps. They don't look bad, they're just different. Too different to not be easily noticeable and to be visually clashing with the full models.

This particular very transparent, very thin texture is proving to be a really tough challenge to transpose into LOD's binary alpha. There are comments from users of that texture replacer mod reporting they tried DynDOLOD's 3D tree LODs "as is" and they thought they looked awful.

I admit I can be somewhat of a mad perfectionist, but I believe it's on-topic and worth exploring possible solutions to accommodate this texture's peculiarity and work around DynDOLOD / LOD limitations or requirements. I'm not a texture artist and the mod author has been inactive for a while, so the process involves a lot of discovery and fumbling.

Please don't hesitate to let me know if this is bothering you. I certainly do not wish to annoy you or abuse your time. If you're expecting DynDOLOD users in such case to "take it or leave it", that's totally fair but needs to be communicated clearly.

Thanks.

[z929669]

@Mousetick Your recent posts relate very much to what DY and I were trying to solve for Aspens Ablaze LODs. You may benefit from that discussion, but I think it's really all related to how the textures are saved with or without proper so-called "alpha-to-coverage" or "alpha scale mipmap coverage threshold" used in the application that generates the DDS by the MA. The NIAlphaProperty acts as a Boolean based on this texture threshold (AFAIK), which uses the same scale (0-254).

• Sheson's response to my post (also expand my post)
• DY's more thorough assessment of the problem than my original - there's several other preceding and subsequent posts in that discussion
• This post shows the consequence of using UseMipMaps when the MA-provided texture alpha thresholds are not great (#3) and how DynDOLOD's algoritm is better (#2) ... and arguably the best approach (unless the MA is doing custom painting at each mip level of correctly-saved textures)

[DoubleYou]

2 hours ago, z929669 said:

@Mousetick Your recent posts relate very much to what DY and I were trying to solve for Aspens Ablaze LODs. You may benefit from that discussion, but I think it's really all related to how the textures are saved with or without proper so-called "alpha-to-coverage" or "alpha scale mipmap coverage threshold" used in the application that generates the DDS by the MA. The NIAlphaProperty acts as a Boolean based on this texture threshold (AFAIK), which uses the same scale (0-254).

• Sheson's response to my post (also expand my post)
• DY's more thorough assessment of the problem than my original - there's several other preceding and subsequent posts in that discussion
• This post shows the consequence of using UseMipMaps when the MA-provided texture alpha thresholds are not great (#3) and how DynDOLOD's algoritm is better (#2) ... and arguably the best approach (unless the MA is doing custom painting at each mip level of correctly-saved textures)

I've learned a lot more since then. Typically the best solution is to resave the base leaf diffuse texture(s) using dilation (to fix color issues) and proper mipmap alpha coverage (to fix the thinness). Don't be afraid to set the alpha coverage high. My workflow:

1. Load texture in Gimp
2. Lock alpha channel
3. Dilate using G'MIC Repair > Solidify filter
4. Export
   • You can export uncompressed and use another tool to save with alpha coverage of the mipmaps as BC7
   • Or you can use native plugin and export as DXT5, use preserve alpha test coverage, and set the threshold to the desired level.

Now when you use the existing mipmaps, the texture should have the same level of coverage in both full and lod. Higher alpha coverage typically results in increased performance as well.

[Mousetick]

26 minutes ago, DoubleYou said:

I've learned a lot more since then. Typically the best solution is to resave the base leaf diffuse texture(s) using dilation (to fix color issues) and proper mipmap alpha coverage (to fix the thinness). Don't be afraid to set the alpha coverage high. My workflow:

That's very helpful, thanks. Fortunately the MA of the branches textures I'm using provides the raw images as PNG so I'm going to give this a try.

[z929669]

1 hour ago, Mousetick said:

That's very helpful, thanks. Fortunately the MA of the branches textures I'm using provides the raw images as PNG so I'm going to give this a try.

My workflow is similar to DY's, but I use Ps to do my work and NVIDIA Texture Tools Exporter to save my textures.

1. Load texture in Ps
2. Use existing texture alpha > Invert mask > remove background
3. Use Solidify C filter (for foliage anyway)
4. Invert alpha again or reload the texture after save
5. Export via NVIDIA Texture Tools Exporter plugin (or stand-alone) with "Scale Alpha for Mipmap Coverage" checked if it's foliage or requires similar alpha/transparency. Threshold usually default 127, but sometimes lower, depending.

Note that you can likely use Paint.net as well. I find Gimp to be unintuitive, so I only use it for things I can't do in other apps when following someone else's workflow for specific applications.

[Mousetick]

4 hours ago, DoubleYou said:

I've learned a lot more since then. Typically the best solution is to resave the base leaf diffuse texture(s) using dilation (to fix color issues) and proper mipmap alpha coverage (to fix the thinness). Don't be afraid to set the alpha coverage high. My workflow:

[...]

Now when you use the existing mipmaps, the texture should have the same level of coverage in both full and lod. Higher alpha coverage typically results in increased performance as well.

2 hours ago, z929669 said:

My workflow is similar to DY's, but I use Ps to do my work and NVIDIA Texture Tools Exporter to save my textures.

[...]

Note that you can likely use Paint.net as well. I find Gimp to be unintuitive, so I only use it for things I can't do in other apps when following someone else's workflow for specific applications.

Thank you both for putting me on the right track.

• I found that no Solidify filter was necessary in my case: it didn't make any difference, probably because the MA may have already applied such kind of filter.
• I found that using high alpha coverage caused the branches mipmaps of the full model to become blocky/blotchy/flat. Even 0.6 (0.6 * 255 = 153) was very noticeable. When the game switches from full texture to mipmap, or switches between mipmap levels, depending on viewing distance, it's very noticeable and jarring.
• I don't mind GIMP for how little I use it.
• Paint.net is nice and easy to use but doesn't have alpha-to-coverage feature when exporting to DDS.

The perfect solution (for me) was "simply" to use 0.51 (0.51 * 255 = 130) for the alpha-to-coverage threshold of the mipmaps when exporting to DDS. This combined with UseMipMaps, and NiAlphaProperty Threshold = 128 (128 being the LOD "native" alpha threshold) in the 3D LOD models, makes DynDOLOD act as a full "passthru" of the original texture mipmaps to the object LOD atlas. I think it makes sense.

The results are absolutely incredible. I cannot believe my eyes. I can hardly tell what is LOD and what is full model. The LOD Level 4 to active cells transitions are practically seamless for trees.

I don't understand what exactly is going on when alpha-to-coverage threshold is 0.5 (0.5 * 255 = 127) and why UseMipMaps produces "bad" results with DynDOLOD that are impossible to fix with NiAlphaProperty Threshold. But it's not really important. The important point in my view is that mod authors who use alpha-to-coverage for mipmaps probably use the default 0.5 (127) threshold, which doesn't sit well with LOD binary alpha threshold of 128.

I'm going to apply the same treatment to the snowy/ashy variants and to the aspen trees. We'll see if this "perfect" solution holds true.

[z929669]

2 hours ago, Mousetick said:

Thank you both for putting me on the right track.

• I found that no Solidify filter was necessary in my case: it didn't make any difference, probably because the MA may have already applied such kind of filter.
• I found that using high alpha coverage caused the branches mipmaps of the full model to become blocky/blotchy/flat. Even 0.6 (0.6 * 255 = 153) was very noticeable. When the game switches from full texture to mipmap, or switches between mipmap levels, depending on viewing distance, it's very noticeable and jarring.
• I don't mind GIMP for how little I use it.
• Paint.net is nice and easy to use but doesn't have alpha-to-coverage feature when exporting to DDS.

The perfect solution (for me) was "simply" to use 0.51 (0.51 * 255 = 130) for the alpha-to-coverage threshold of the mipmaps when exporting to DDS. This combined with UseMipMaps, and NiAlphaProperty Threshold = 128 (128 being the LOD "native" alpha threshold) in the 3D LOD models, makes DynDOLOD act as a full "passthru" of the original texture mipmaps to the object LOD atlas. I think it makes sense.

The results are absolutely incredible. I cannot believe my eyes. I can hardly tell what is LOD and what is full model. The LOD Level 4 to active cells transitions are practically seamless for trees.

I don't understand what exactly is going on when alpha-to-coverage threshold is 0.5 (0.5 * 255 = 127) and why UseMipMaps produces "bad" results with DynDOLOD that are impossible to fix with NiAlphaProperty Threshold. But it's not really important. The important point in my view is that mod authors who use alpha-to-coverage for mipmaps probably use the default 0.5 (127) threshold, which doesn't sit well with LOD binary alpha threshold of 128.

I'm going to apply the same treatment to the snowy/ashy variants and to the aspen trees. We'll see if this "perfect" solution holds true.

Great to know. I like the inclusion of an equation, since it makes things simpler for me to remember. It looks like you are incorporating a small correction factor with ((0.5 + 0.01) * 255) = 130, and that is nice to have.

Now my question is what is the analogous formula used by the DynDOLOD TexConv process? I assume it must be 0.5 * 255 = 128 (rounding from 127.5), and why the small correction factor is just enough to resolve in your use case? Does this theoretically apply to every use case where texture alpha mipmap thresholds apply (e.g., foliage, fur/hair, smoke, etc.)? Finally, what is the 'best' value for NiAlphaProperty in the mesh given a texture alpha threshold of 130? Would it be 128, 130, or something else ... or dependent upon the whim of the mesh artist and other factors?

PS: I mentioned Paint.net because you could save the PNG after making changes via that program and then use something like NVIDIA Texture Tools (NTT) to save as DDS (instead of Ps or Gimp if those are not accessible/convenient). It may even have a plugin extension for NTT, but I haven't checked that for a while.

Also, you can tell if Solidify was applied by looking at the texture without the alpha mask. I like Solidify C for foliage, since it extends the edge colors inside the exposed alpha in a radial fashion into the transparency so that mip levels don't get color bias if the mips are imperfect (which they always are as mip level increases). Incedentally, I've found that slightly darkening the resulting colors in the transparency also works very nicely for foliage (this is what vanilla does in most cases).

[Mousetick]

22 minutes ago, z929669 said:

It looks like you are incorporating a small correction factor with ((0.5 + 0.01) * 255) = 130, and that is nice to have.

I wanted to use 0.503 (0.503 * 255 = 128) but GIMP only allow 2 digits after the decimal point, so it was 0.51. I think that's fine (by the looks of it in-game) and it's probably safer to have some small margin above 128. Further tests would be required but I'm really tired of testing this stuff

19 minutes ago, z929669 said:

Now my question is what is the analogous formula used by the DynDOLOD TexConv process?

This was explained earlier by sheson:

11 hours ago, sheson said:

DynDOLOD uses its own algorithm to adjust alpha. It is based on the principle that each mipmap is 1/4 of the one before it. Texconv uses a different method.

That was programmed before xLODGen/DynDOLOD needed to use Texconv because of BC5/6/7 compression - in fact I believe Texconv didn't have alpha-to-coverage function when we started using it.
I tested it a bit but never achieved better results that would have warranted going through external command line program for each texture added to the atlas.

 

19 minutes ago, z929669 said:

Finally, what is the 'best' value for NiAlphaProperty in the mesh given a texture alpha threshold of 130? Would it be 128, 130, or something else ... or dependent upon the whim of the mesh artist and other factors?

128 so that DynDOLOD doesn't perform any adjustment. Also explained earlier by sheson:

Quote

If the threshold is the default 128, then there also is no threshold adjustment done by DynDOLOD.

[sheson]

11 hours ago, Mousetick said:

Here are the full logs if you wish to look at them: https://drive.google.com/file/d/1ZNmpBzlHU1rrC1c6wjzUTRdPlMxaG-Qj/view

There isn't much to show in the console when looking at LODs, but here are the console shots of the tree full models that were discussed in previous post:

Based on that information I doublechecked that the source the texture and its mipmaps are used as is.

11 hours ago, Mousetick said:

As discussed and shown previously, the mipmaps generated by DynDOLOD look very different than the full texture mipmaps. They don't look bad, they're just different. Too different to not be easily noticeable and to be visually clashing with the full models.

The problem is the original source texture is being replaced by a full texture with mipmaps that do not have alpha-to -coverage. While the full model fades into nothingness until it switches to LOD, the LOD has a texture that doesn't. This can quickly be mitigated by adjusting the alpha threshold of the LOD model, so that the two texture roughly match when they switch, with is not a constant distance/mipmap or with more work by using the same texture unmodified texture for both. Which you achieved.

11 hours ago, Mousetick said:

This particular very transparent, very thin texture is proving to be a really tough challenge to transpose into LOD's binary alpha. There are comments from users of that texture replacer mod reporting they tried DynDOLOD's 3D tree LODs "as is" and they thought they looked awful.

You mean this?

Quote

I like this mod (definitely vanilla ++), but after running Dyndo 3 with 3D ultra LOD settings, like I normally use for HLT, but the end result was all wonky - 2d images and flickering everywhere. I thought Dyndo would generate the 3d LOD itself as this is based on vanilla trees, which the Dyndolod instructions say can produce 3d ultra LOD from, but that didn't happen. 
I must be doing something wrong, anyone got any idea?

Quote

I don't think you're doing anything wrong, I tried to gen 3d lods with these textures too and you do technically get 3d lods, they just look awful, kinda like vanilla 3d lods, but worse. I guess we'd need better 3d lod resources

In any case, people posting about LOD related problems anywhere else but here might as well be yelling at clouds.

11 hours ago, Mousetick said:

I admit I can be somewhat of a mad perfectionist, but I believe it's on-topic and worth exploring possible solutions to accommodate this texture's peculiarity and work around DynDOLOD / LOD limitations or requirements. I'm not a texture artist and the mod author has been inactive for a while, so the process involves a lot of discovery and fumbling.

Please don't hesitate to let me know if this is bothering you. I certainly do not wish to annoy you or abuse your time. If you're expecting DynDOLOD users in such case to "take it or leave it", that's totally fair but needs to be communicated clearly.

Thanks.

You have problems with a full texture with bad mipmaps that do not have alpha-to-coverage.
Changing full textures or its mipmaps to your satisfaction is outside my purview and somewhat off-topic for the DynDOLOD 3 Alpha test since the build-in options/features are disabled to give you full control. The mipmap fading happens with or without the texture being used for LOD.

[sheson]

6 hours ago, Mousetick said:

Thank you both for putting me on the right track.

• I found that no Solidify filter was necessary in my case: it didn't make any difference, probably because the MA may have already applied such kind of filter.
• I found that using high alpha coverage caused the branches mipmaps of the full model to become blocky/blotchy/flat. Even 0.6 (0.6 * 255 = 153) was very noticeable. When the game switches from full texture to mipmap, or switches between mipmap levels, depending on viewing distance, it's very noticeable and jarring.
• I don't mind GIMP for how little I use it.
• Paint.net is nice and easy to use but doesn't have alpha-to-coverage feature when exporting to DDS.

The perfect solution (for me) was "simply" to use 0.51 (0.51 * 255 = 130) for the alpha-to-coverage threshold of the mipmaps when exporting to DDS. This combined with UseMipMaps, and NiAlphaProperty Threshold = 128 (128 being the LOD "native" alpha threshold) in the 3D LOD models, makes DynDOLOD act as a full "passthru" of the original texture mipmaps to the object LOD atlas. I think it makes sense.

The results are absolutely incredible. I cannot believe my eyes. I can hardly tell what is LOD and what is full model. The LOD Level 4 to active cells transitions are practically seamless for trees.

I don't understand what exactly is going on when alpha-to-coverage threshold is 0.5 (0.5 * 255 = 127) and why UseMipMaps produces "bad" results with DynDOLOD that are impossible to fix with NiAlphaProperty Threshold. But it's not really important. The important point in my view is that mod authors who use alpha-to-coverage for mipmaps probably use the default 0.5 (127) threshold, which doesn't sit well with LOD binary alpha threshold of 128.

I'm going to apply the same treatment to the snowy/ashy variants and to the aspen trees. We'll see if this "perfect" solution holds true.

Checking the source code of Texconv it is value * 255 + 0.5
so 0.5 * 255 + 0.5 = 128.

Shaders typically do not switch between mipmaps but blend/filter.

[sheson]

4 hours ago, z929669 said:

Great to know. I like the inclusion of an equation, since it makes things simpler for me to remember. It looks like you are incorporating a small correction factor with ((0.5 + 0.01) * 255) = 130, and that is nice to have.

Now my question is what is the analogous formula used by the DynDOLOD TexConv process? I assume it must be 0.5 * 255 = 128 (rounding from 127.5), and why the small correction factor is just enough to resolve in your use case? Does this theoretically apply to every use case where texture alpha mipmap thresholds apply (e.g., foliage, fur/hair, smoke, etc.)? Finally, what is the 'best' value for NiAlphaProperty in the mesh given a texture alpha threshold of 130? Would it be 128, 130, or something else ... or dependent upon the whim of the mesh artist and other factors?

PS: I mentioned Paint.net because you could save the PNG after making changes via that program and then use something like NVIDIA Texture Tools (NTT) to save as DDS (instead of Ps or Gimp if those are not accessible/convenient). It may even have a plugin extension for NTT, but I haven't checked that for a while.

Also, you can tell if Solidify was applied by looking at the texture without the alpha mask. I like Solidify C for foliage, since it extends the edge colors inside the exposed alpha in a radial fashion into the transparency so that mip levels don't get color bias if the mips are imperfect (which they always are as mip level increases). Incedentally, I've found that slightly darkening the resulting colors in the transparency also works very nicely for foliage (this is what vanilla does in most cases).

DynDOLOD uses Texconv to convert compression formats only. The formula for scaled alpha coverage for a mipmap is alpha *= 1 + MipMapLevel * AlphaFactor.
MipMapLevel is 0 for the largest mipmap, so no change. DynDOLOD_SSE.INI sets AlphaFactor=0.25 because each mipmap is 1/4 of the resolution of the one before it.

A texture has an alpha channel. The game uses alpha testing, the alpha test threshold value is used together with the alpha test function (greater than) to determine if a pixel shows or not. So, whenever the alpha value of a pixel is greater than the default 128 threshold, it is opaque. The best value for the NiAlphaProperty of full/LOD models would be 128, because that matches the hardcoded LOD threshold and no adjustment of the texture alpha channel is required if it is added to the texture atlas.

So I assume the alpha channel of the texture should probably be made with the default threshold of > 128 (0.50196) in mind.

[DoubleYou]

6 hours ago, Mousetick said:

Thank you both for putting me on the right track.

• I found that no Solidify filter was necessary in my case: it didn't make any difference, probably because the MA may have already applied such kind of filter.
• I found that using high alpha coverage caused the branches mipmaps of the full model to become blocky/blotchy/flat. Even 0.6 (0.6 * 255 = 153) was very noticeable. When the game switches from full texture to mipmap, or switches between mipmap levels, depending on viewing distance, it's very noticeable and jarring.
• I don't mind GIMP for how little I use it.
• Paint.net is nice and easy to use but doesn't have alpha-to-coverage feature when exporting to DDS.

The perfect solution (for me) was "simply" to use 0.51 (0.51 * 255 = 130) for the alpha-to-coverage threshold of the mipmaps when exporting to DDS. This combined with UseMipMaps, and NiAlphaProperty Threshold = 128 (128 being the LOD "native" alpha threshold) in the 3D LOD models, makes DynDOLOD act as a full "passthru" of the original texture mipmaps to the object LOD atlas. I think it makes sense.

The results are absolutely incredible. I cannot believe my eyes. I can hardly tell what is LOD and what is full model. The LOD Level 4 to active cells transitions are practically seamless for trees.

I don't understand what exactly is going on when alpha-to-coverage threshold is 0.5 (0.5 * 255 = 127) and why UseMipMaps produces "bad" results with DynDOLOD that are impossible to fix with NiAlphaProperty Threshold. But it's not really important. The important point in my view is that mod authors who use alpha-to-coverage for mipmaps probably use the default 0.5 (127) threshold, which doesn't sit well with LOD binary alpha threshold of 128.

I'm going to apply the same treatment to the snowy/ashy variants and to the aspen trees. We'll see if this "perfect" solution holds true.

I notice in your snow trees they start to turn purple, which is why I said to use dilation to fix this. 

There should be no magic at threshold 127 vs 128 vs 130. The fix here is merely that the mod author failed to use alpha coverage when generating mipmaps, and you have fixed that, so as long as all thresholds are the same, the transition is seamless. 

[Mousetick]

2 hours ago, DoubleYou said:

so as long as all thresholds are the same, the transition is seamless. 

All thresholds of what? Same as what? Which transition? Please be specific.

I explained that I want to use NiAlphaProperty Threshold of 128. This is in order to preserve the alpha channel of the original branches texture's mipmaps when copied to the object LOD atlas, so that there are zero differences between the LOD mipmaps and the full model mipmaps.

[Mousetick]

5 hours ago, sheson said:

Checking the source code of Texconv it is value * 255 + 0.5
so 0.5 * 255 + 0.5 = 128.

Interesting. I haven't tried Texconv. For my tests, I only used GIMP's export to DDS feature, which has many bells and whistles, but doesn't support the newer compression formats.

5 hours ago, sheson said:

Shaders typically do not switch between mipmaps but blend/filter.

Yes you're right. I didn't use the correct word. The previous and next mipmaps levels appear to "crossfade" in-game.