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]

9 hours ago, z929669 said:

Thanks but replying with the doc text doesn't help me much. I was looking for explicit answers to my questions. I think I understand most of this, but could your reply directly to the following(?):

Does DynDOLOD read NiAlphaProperty of say, 80, and then generate alpha-to-coverage using threshold 80?

No it does not.

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that LOD only has binary alpha with a fixed threshold of 128. DynDOLOD reads the alpha threshold from the NiAlphaProperty from the models used for LOD and adjusts the textures before it is added to the atlas texture. The final result in game may be to thick or thin like certain objects seem to be missing or transparency looks off. Try adjusting the NiAlphaProperty in the 3D LOD model.

There is no mention in this paragraph about alpha-to-coverage.

I already wote:

These are two different things.
There is no mention of "UseMipMaps" in this paragraph. That means it has no effect on adjusting the alpha to work with the hardcoded alpha threshold.
This paragraph explains what "UseMipmaps" does. It instructs DynDOLOD to not generate mipmaps but use the ones from the texture. Note how this paragraph does not mention the alpha threshold or NiAlphaProperty.

The scaled alpha-to-coverage does not contain a threshold value.
https://stepmodifications.org/forum/topic/19077-optimizing-texture-alpha-threshold/?do=findComment&comment=274456
https://stepmodifications.org/forum/topic/19077-optimizing-texture-alpha-threshold/?do=findComment&comment=274469

 

[sheson]

7 hours ago, Mousetick said:

This doesn't quite answer what I was trying to ask.

The question: Could you please confirm strictly greater than or greater than or equal?
The answer: the alpha test function of LOD uses greater than

https://stepmodifications.org/forum/topic/19077-optimizing-texture-alpha-threshold/?do=findComment&comment=274456

7 hours ago, Mousetick said:

The BTO mesh doesn't have any NiAlphaProperty with operator flags or threshold, so we don't know if it's greater than or greater than or equal, or if the threshold is 127 or 128.

I tested it using community shaders. The AlphaThreshold value is 128 / 255.
FO4 BTOs support NiAlphaProperty. The vanilla BTO files also default to a threshold of 128 and greater than.

7 hours ago, Mousetick said:

But if it is true, then this has huge implications that ripple down the whole chain. Starting with DynDOLOD adjustment of mipmaps alpha: the correct "neutral" value should be 129, not 128. Etc...

The default threshold value in NIFs, the game and tools is 128. NIFs typically define greater than as the test function. It is the default method.
The used test function does not change the fact that the default threshold is 128. If the NIF defines another value, than the alpha channel is adjusted.
You would need a very specific alpha channel at full 8 bit resolution too see a difference between one specific step at typical view distances. You can test that in NIfSkope.

7 hours ago, Mousetick said:

How does one go from a threshold to a multiplication factor?

Rule of three. We have old alpha value, old threshold and new threshold.

7 hours ago, Mousetick said:

What happens exactly in the case of UseMipMaps?

Logic dictates that if the alpha channel needs to be adjusted, it always happens to all mipmap levels regardless their source.

In case the threshold is not the default value, the alpha channel adjustment is applied to all mipmap levels.

[Mousetick]

3 hours ago, sheson said:

I tested it using community shaders. The AlphaThreshold value is 128 / 255.

The key point for me to understand, and for texture artists as well I'd guess, is what is the minimum alpha value that passes the LOD alpha test:

• 127: transparent or opaque?
• 128: transparent or opaque?
• 129: transparent or opaque?

4 hours ago, sheson said:

FO4 BTOs support NiAlphaProperty. The vanilla BTO files also default to a threshold of 128 and greater than.

This makes no sense, but it's Bethesda.

4 hours ago, sheson said:

The default threshold value in NIFs, the game and tools is 128. NIFs typically define greater than as the test function. It is the default method.
The used test function does not change the fact that the default threshold is 128. If the NIF defines another value, than the alpha channel is adjusted.

If DynDOLOD uses 128 then it means you consider that the minimum alpha value that passes the test is 128.

There are only two alpha test functions that would produce this result:

• Greater than 127
• Greater than or equal to 128

Neither of which is 'Greater than 128'. Would you agree? If you agree, then this contradicts your previous statements:

Quote

As already mentioned earlier, the alpha test function of LOD uses greater than, just as the default NiAlphaProperty.

The default threshold of object LOD is 128 and it always does alpha testing with greater than.

It doesn't matter what the NIF default is for LOD and I don't understand why you keep bringing that up. All that matters is what the game actually does, and what you were able to observe and determine based on your Community Shaders tests.

4 hours ago, sheson said:

You would need a very specific alpha channel at full 8 bit resolution too see a difference between one specific step at typical view distances. You can test that in NIfSkope.

It depends on the texture. If large pieces of the texture use a constant alpha channel, it's important to get the alpha value or the alpha test right. Even more important when preparing mipmaps for LOD.

Example using a vanilla tree. I made a solid white texture with constant 128 alpha (50% opaque) for demonstration purpose. Results in NifSkope:

• Initially the NIF uses Greater than 112 as the alpha test function:

• Then I change the threshold to 127, so the alpha test function is now Greater than 127, still opaque:

• Then I change the threshold to 128, so the alpha test function is now Greater than 128, everything's gone:

Thanks.

[sheson]

1 hour ago, Mousetick said:

The key point for me to understand, and for texture artists as well I'd guess, is what is the minimum alpha value that passes the LOD alpha test:

• 127: transparent or opaque?
• 128: transparent or opaque?
• 129: transparent or opaque?

This makes no sense, but it's Bethesda

The default alpha threshold of object LOD is 128 and the alpha test function is greater than. That means if the alpha value of a pixel is > 128 it is opaque.
It most likely is that way since decades/ever through all game versions. If you add a new NiAlphaProperty with NifSkope it defaults to alpha testing, a threshold of 128 and the greater than alpha test function.

1 hour ago, Mousetick said:

If DynDOLOD uses 128 then it means you consider that the minimum alpha value that passes the test is 128.

The game uses a default object LOD threshold of 128. NifSkope sets a default threshold of 128.
DynDOLOD compares if the threshold value of a NiAlphaProperty in a NIF equals the default threshold value of 128.
If the threshold value of a NiAlphaProperty in a NIF is not the default value of 128, then the alpha channel of the corresponding texture is adjusted by using simple math before it is added to the object LOD texture atlas. The alpha values are multiplied with a factor. The alpha values are not compared.

1 hour ago, Mousetick said:

Then I change the threshold to 128, so the alpha test function is now Greater than 128, everything's gone:

Yes, as explained, this is what the game does, default threshold of 128 and greater than alpha test function.

1 hour ago, Mousetick said:

It depends on the texture. If large pieces of the texture use a constant alpha channel,

As I said, you would need a very specific texture with the exact threshold for it to actually matter.
Typically textures have large areas of 0 and 255 while border pixels have any of the 254 values in between. Some may even be 128 exactly.
Change the alpha test function in NifSkope to equal in order to see them.

[Mousetick]

I wasn't super-happy with the aspen mipmaps which were duller in color than the full texture. I found that enabling gamma correction fixed the problem.

Much better.

I've been using GIMP's mipmap generation, with Lanczos sampling filter. There are other filters like Mitchell and Kaiser, which I compared to Lanczos and didn't find much difference.

I briefly tried Microsoft Texconv with its Cubic and newfangled FaNT filter. The results were a disaster. But I may not have used the correct options. This needs more testing.

I found it useful to examine the mipmaps in an image editing tool to check them up before running DynDOLOD and looking at them in-game. If your image editing program can't directly open DDS mipmap levels as individual images, the Texdiag program from Microsoft can extract all mipmap levels of an uncompressed DDS and store them as separate images.

[Mousetick]

2 hours ago, sheson said:

The default alpha threshold of object LOD is 128 and the alpha test function is greater than. That means if the alpha value of a pixel is > 128 it is opaque.

I don't know why it's difficult for you to answer the question: is alpha 128 transparent or opaque in LOD?

You don't need to keep repeating the same things over and over. I know what you're saying.

Anyway, I went and tried it myself. Using the same white texture as in the previous NifSkope test: solid white, all alpha 128. This texture's mipmaps were not generated with alpha-to-coverage.

LOD ON | LOD OFF

What do you make of this? If alpha 128 is opaque in LOD, either the alpha test function is 'Greater than 127', or the function 'Greater than 128', that you claim is being used, doesn't work. I'm inclined to believe it's the former.

Thanks.

[z929669]

All of this back and forth we are having on the alpha test threshold seems so unnecessary. We are unable to get explicit answers to explicit questions. The answers are always implicit based upon previous statements in posts or in the doc.

I intuitively KNOW that all of my own confusion is because we have multiple conflating sources of alpha variance:

1. Alpha-to-coverage threshold defined within the texture data itself
2. NiAlphaProperty testing alpha threshold defined in the LOD model
3. Alpha-to-coverage threshold defined withing the DynDOLOD atlas texture
4. NiAlphaProperty testing alpha threshold defined in the BTO
5. "LOD binary alpha fixed threshold" (is this the BTO??)
6. '>' vs '≥' interpretation of NiAlphaProperty testing threshold, which can be different between #2 and #4

Therefore, I intuitively KNOW that my own understanding can come only with more explicit answers and examples that differ from the doc and what has previously been posted (largely quoting the doc). I understand if holding my hand is too much effort, so do not feel obligated. I'm basically only suggesting that a change from the present semantics and tactics of explanation could be improved for me and thus others like me (and thus may result in far less Q&A going forward).

I mean no offense, but I must accept that I am incapable of full understanding without completing a minimum of 32 independent tests of my own once I get the funding.

Here's what I assume:

1. Texture Alpha: B/W value of a pixel (0-255) with 0 being black (transparent) and 255 being white (opaque). It's information in the texture.
2. Alpha-to-coverage: Scaling algorithm used to extrapolate Texture Alpha downscaling to smaller-resolution mipmaps. It's information in the texture.
3. Alpha-to-coverage Threshold: The Texture Alpha value '≤' at which a given pixel is opaque (white). It's information in the texture.
4. NiAlphaProperty: The alpha-testing value '<' at which the Texture Alpha is opaque. It's information in the model.

DynDOLOD could impact each one of these at any given time in its processing the resulting BTO and corresponding texture atlas, but I'm not entirely clear on which it impacts at any given time. All I think I know is that if UseMipMaps is in the Shape Name, then DynDOLOD does not make any changes to #2 and #3 (and probably not #1 either). Given that all of those 4 definitions apply to BOTH input LOD model/textures AND to resulting DynDOLOD BTO/texture atlas, there's additional degrees of freedom to keep straight.

[sheson]

In this context:
A texture is an image. It is comprised of pixels.
A DXT5/BC7 texture may have up to 4 channels. Each channel can have values between 0 and 255.
In case of diffuse textures, the 4 channels represent red, green, blue and alpha.
A texture can have multiple images in one file, for example mipmaps.

3 hours ago, z929669 said:

1. Alpha-to-coverage threshold defined within the texture data itself

There is no such thing. See above.

3 hours ago, z929669 said:

2. NiAlphaProperty testing alpha threshold defined in the LOD model

Yes.

3 hours ago, z929669 said:

3. Alpha-to-coverage threshold defined withing the DynDOLOD atlas texture

There is no such thing. See above.

3 hours ago, z929669 said:

4. NiAlphaProperty testing alpha threshold defined in the BTO

Only Fallout 4 supports NiAlphaProperty in BTOs . In older games it is ignored. The games have hardcoded settings instead.

3 hours ago, z929669 said:

5. "LOD binary alpha fixed threshold" (is this the BTO??)

The default threshold of 128 for LOD is hardcoded in the game.

3 hours ago, z929669 said:

6. '>' vs '≥' interpretation of NiAlphaProperty testing threshold, which can be different between #2 and #4

The alpha test function is an option of the NiAlphaProperty. In case of LOD it is hardcoded to be greater than, unless in Fallout 4.

3 hours ago, z929669 said:

1. Texture Alpha: B/W value of a pixel (0-255) with 0 being black (transparent) and 255 being white (opaque). It's information in the texture.

A DXT1 has such 1 bit transparency information. DXT5/BC7 have an alpha channel with values between 0 and 255.

3 hours ago, z929669 said:

2. Alpha-to-coverage: Scaling algorithm used to extrapolate Texture Alpha downscaling to smaller-resolution mipmaps. It's information in the texture.

Alpha-to-coverage describes an algorithm. It is used to change the values of an alpha channel. As in read the alpha value from texture, change it, write alpha value to the texture.

3 hours ago, z929669 said:

3. Alpha-to-coverage Threshold: The Texture Alpha value '≤' at which a given pixel is opaque (white). It's information in the texture.

Alpha-to-coverage algorithms multiply alpha values with a factor. There are no less, greater than comparisons 

3 hours ago, z929669 said:

4. NiAlphaProperty: The alpha-testing value '<' at which the Texture Alpha is opaque. It's information in the model.

The NiAlphaProperty of the model/shape has several different settings. 
The alpha test function is typically set to greater than, which means if the alpha value of a pixel is "greater than" the "alpha threshold" it is opaque.

3 hours ago, z929669 said:

DynDOLOD could impact each one of these at any given time in its processing the resulting BTO and corresponding texture atlas, but I'm not entirely clear on which it impacts at any given time. All I think I know is that if UseMipMaps is in the Shape Name, then DynDOLOD does not make any changes to #2 and #3 (and probably not #1 either). Given that all of those 4 definitions apply to BOTH input LOD model/textures AND to resulting DynDOLOD BTO/texture atlas, there's additional degrees of freedom to keep straight.

The two different features "alpha channel adjustment" and "mipmap generation with alpha-to-coverage" affect the values of the alpha channels of textures that are being added to the object LOD atlas.

[z929669]

3 hours ago, sheson said:

In this context:
A texture is an image. It is comprised of pixels.
A DXT5/BC7 texture may have up to 4 channels. Each channel can have values between 0 and 255.
In case of diffuse textures, the 4 channels represent red, green, blue and alpha.
A texture can have multiple images in one file, for example mipmaps.

There is no such thing. See above.

Yes.

There is no such thing. See above.

Only Fallout 4 supports NiAlphaProperty in BTOs . In older games it is ignored. They have hardcoded settings instead.

The default threshold of 128 for LOD is hardcoded in the game.

The alpha test function is an option of the NiAlphaProperty. In case of LOD it is hard coded to be greater than.

A DXT1 has such 1 bit transparency information. DXT5/BC7 have an alpha channel with values between 0 and 255.

Alpha-to-coverage describes an algorithm. It is used to change the values of an alpha channel.

Alpha-to-coverage algorithms multiply alpha values with a factor - as read alpha value from texture, change it, write alpha value to texture.
There are no less, greater than comparisons.

The NiAlphaProperty of the model/shape has several different settings. 
The alpha test function is typically set to greater than, which means if the alpha value of a pixel is "greater than" the "alpha threshold" it is opaque.

The two different features "alpha channel adjustment" and "mipmap generation with alpha-to-coverage" affect the values of the alpha channels of textures that are being added to the object LOD atlas.

Thanks for taking the time to read and reply. It's much appreciated. I'll consider all of this carefully before responding if I need to.

[sheson]

17 hours ago, Mousetick said:

Anyway, I went and tried it myself. Using the same white texture as in the previous NifSkope test: solid white, all alpha 128. This texture's mipmaps were not generated with alpha-to-coverage.

LOD ON | LOD OFF

What do you make of this? If alpha 128 is opaque in LOD, either the alpha test function is 'Greater than 127', or the function 'Greater than 128', that you claim is being used, doesn't work. I'm inclined to believe it's the former.

Thanks.

Using Community Shaders, adding this condition to the end of Lighting.hlsl makes everything with an AlphaThreshold of 128 have a red tint.

if (AlphaThreshold == 128.0/255.0) {
   psout.Albedo.r = 1;
}
return psout;
As a result object/terrain LOD has a red tint. Which means the default alpha threshold of LOD send to the shader is 128.

I found a test function in Lighting.hlsl. In this case it actually translates to greater/equal than instead of greater than.
if (alpha - AlphaThreshold < 0) {
    discard;
}
If the alpha value of a pixel is equal to AlphaThreshold, then the result is not less than 0, then it is not discarded, which means it is opaque.
So this function means a pixel with an alpha value of 128 is opaque and a pixel with an alpha value of 127 is transparent.
This is most likely not the only alpha testing being done in the pipeline.

For a test change the condition so that 128 is transparent as well:
if (alpha - AlphaThreshold <= 0)
and check if it makes a difference with your test texture and if you can see a visual difference for typical textures.

[Mousetick]

18 hours ago, sheson said:

Using Community Shaders, adding this condition to the end of Lighting.hlsl makes everything with an AlphaThreshold of 128 have a red tint.

if (AlphaThreshold == 128.0/255.0) {
   psout.Albedo.r = 1;
}
return psout;
As a result object/terrain LOD has a red tint. Which means the default alpha threshold of LOD send to the shader is 128.

I found a test function in Lighting.hlsl. In this case it actually translates to greater/equal than instead of greater than.
if (alpha - AlphaThreshold < 0) {
    discard;
}
If the alpha value of a pixel is equal to AlphaThreshold, then the result is not less than 0, then it is not discarded, which means it is opaque.
So this function means a pixel with an alpha value of 128 is opaque and a pixel with an alpha value of 127 is transparent.
This is most likely not the only alpha testing being done in the pipeline.

For a test change the condition so that 128 is transparent as well:
if (alpha - AlphaThreshold <= 0)
and check if it makes a difference with your test texture and if you can see a visual difference for typical textures.

I'm not sure I'm going to test with Community Shaders, I'd rather not add another (unknown/unproven) layer in the middle. But thanks for the information, it could be useful if needed.

With or without Community Shaders, I've hit a roadblock anyway. The previous test I made is invalid. I discovered that the mipmaps copied to the atlas by DynDOLOD have been changed. The source texture and its mipmaps are R:255 G:255 B:255 A:128 for all pixels. In the atlas it has become R:255 G:255 B:255 A:255.

Before that discovery I had made a more elaborate version of the test texture with a R:255 G:255 B:255 A:128 background and some small R:255 G:255 B:255 A:127 rectangles partially covering the area where branches are normally placed in treepineforestbranchcomp.dds. In that case, DynDOLOD also changed the mipmaps: R:255 G:255 B:255 A:128 background became R:255 G:255 B:255 A:255, and R:255 G:255 B:255 A:127 rectangles became R:255 G:255 B:255 A:254.

I have no idea what's going on but this is completely unexpected. This looks like alpha-adjustment gone wrong. No changes were made other than using a specially prepared treepineforestbranchcomp.dds texture. All LOD models have not been touched, they're all using Alpha Threshold 128, which should "neutralize" DynDOLOD's alpha-adjustment. I double-checked the source texture mipmaps, they all have correct alpha channel values.

This is how the specially crafted texture mipmaps look on full models in-game. It's all a bit messy and you may need to zoom in but you can see some branches have "holes" in them, showing the background through, corresponding to the R:255 G:255 B:255 A:127 rectangles. These full models have been configured with NiAlphaProperty Greater Than 127.

I intended to replicate this test on the LODs.

Could you share the exact formula/algorithm that DynDOLOD uses for adjusting the alpha channel?

Thanks.

[sheson]

6 hours ago, Mousetick said:

I'm not sure I'm going to test with Community Shaders, I'd rather not add another (unknown/unproven) layer in the middle. But thanks for the information, it could be useful if needed.

With or without Community Shaders, I've hit a roadblock anyway. The previous test I made is invalid. I discovered that the mipmaps copied to the atlas by DynDOLOD have been changed. The source texture and its mipmaps are R:255 G:255 B:255 A:128 for all pixels. In the atlas it has become R:255 G:255 B:255 A:255.

Before that discovery I had made a more elaborate version of the test texture with a R:255 G:255 B:255 A:128 background and some small R:255 G:255 B:255 A:127 rectangles partially covering the area where branches are normally placed in treepineforestbranchcomp.dds. In that case, DynDOLOD also changed the mipmaps: R:255 G:255 B:255 A:128 background became R:255 G:255 B:255 A:255, and R:255 G:255 B:255 A:127 rectangles became R:255 G:255 B:255 A:254.

I have no idea what's going on but this is completely unexpected. This looks like alpha-adjustment gone wrong. No changes were made other than using a specially prepared treepineforestbranchcomp.dds texture. All LOD models have not been touched, they're all using Alpha Threshold 128, which should "neutralize" DynDOLOD's alpha-adjustment. I double-checked the source texture mipmaps, they all have correct alpha channel values.

This is how the specially crafted texture mipmaps look on full models in-game. It's all a bit messy and you may need to zoom in but you can see some branches have "holes" in them, showing the background through, corresponding to the R:255 G:255 B:255 A:127 rectangles. These full models have been configured with NiAlphaProperty Greater Than 127.

I intended to replicate this test on the LODs.

Could you share the exact formula/algorithm that DynDOLOD uses for adjusting the alpha channel?

Thanks.

If threshold < 128 alpha *= 128 / threshold
If threshold > 128 alpha ^= 1 / (128 / threshold * 2 - 1)

[Mousetick]

4 hours ago, sheson said:

If threshold < 128 alpha *= 128 / threshold
If threshold > 128 alpha ^= 1 / (128 / threshold * 2 - 1)

Ok. The results I'm getting are definitely unexpected then.

It gets weirder. I added two rectangles to the previous test texture: one with Alpha 0, one with Alpha 255. In the atlas the mipmap is all Alpha 255, except the rectangle with Alpha 0 is still Alpha 0, but its border is Alpha 160.

I'm beginning to think the changes are not caused by the alpha-adjustment which should be a no-op based on the code you gave. Perhaps the alpha channel is altered when the atlas is resaved and compressed?

Am I assuming correctly that DynDOLOD creates an uncompressed atlas first and then compresses it with Texconv? If so could you provide the Texconv command line that DynDOLOD runs?

Also, from DynDOLOD_SSE.ini:

; 0 = no mipmaps, 1 = texconv, 2 = internally
ObjectLODGenerateMipMaps=2
TreeLODGenerateMipMaps=2

What would happen if I set ObjectLODGenerateMipMaps=0 with UseMipMaps? Are the source texture mipmaps still going to be copied to the atlas, or are they going to be skipped?

Thanks.

[sheson]

36 minutes ago, Mousetick said:

I'm beginning to think the changes are not caused by the alpha-adjustment which should be a no-op based on the code you gave. Perhaps the alpha channel is altered when the atlas is resaved and compressed?

Texture compression changes the actual channel values of pixels. As mentioned before, if a texture relies on a specific alpha value it would need to be uncompressed.

36 minutes ago, Mousetick said:

I'm beginning to think the changes are not caused by the alpha-adjustment which should be a no-op based on the code you gave. Perhaps the alpha channel is altered when the atlas is resaved and compressed?

The debug log shows it:
[ConvertTexturesThreadAdd] <Debug: [*\DynDOLOD*DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds] Executing "*\DynDOLOD\Edit Scripts\Texconvx64.exe" -nologo -gpu 0 -y -aw 256 -f BC7_UNORM -bc q -o "*\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD">
I do not remember why it sets -aw 256, AFAIK it should not change the alpha values itself.

36 minutes ago, Mousetick said:

What would happen if I set ObjectLODGenerateMipMaps=0 with UseMipMaps? Are the source texture mipmaps still going to be copied to the atlas, or are they going to be skipped?

ObjectLODGenerateMipMaps=0 does not affect how UseMipMaps or mipmap creation in its absence works. It just means the atlas texture has no further mipmap levels and thus mipmaps with resolutions other than the ones being used do not need to copied or created.

[Mousetick]

5 hours ago, sheson said:

Texture compression changes the actual channel values of pixels. As mentioned before, if a texture relies on a specific alpha value it would need to be uncompressed.

That's right. There is mipmap resampling which changes the ARGB values too. But compression and resampling only create marginal errors and/or small gradations between values.

Changing the alpha from 128 to 255 and from 127 to 254 is something else. I haven't been able to pinpoint what it is.

--

I had this idea of a drastic brute-force approach in the back of my mind for some time, but wasn't sure how to practically do it. Directly edit a previously generated object LOD atlas and paste in the special textures for alpha test testing, completely bypassing DynDOLOD. After much fumbling, I managed to achieve that by using uncompressed atlas textures.

Results using a solid green pine branches texture: Alpha 127 > 128 > 129

So you were right all along, of course LOD alpha test is > 128 (or >= 129). I wouldn't believe it initially because it doesn't make logical or mathematical sense to me, and the rationale for it is unknown.

For texture artists preparing mipmaps with alpha-to-coverage, the target should be at least 129 opacity, rather than 128, for consistency with LODs.

It may be helpful to clarify the documentation on https://dyndolod.info/Help/3D-Tree-LOD-Model:

Quote

Note that LOD only has binary alpha with a fixed threshold of 128.

This refers implicitly to the NIF NiAlphaProperty default alpha test of Greater than 128. This can be ambiguous for readers not familiar with the context or the terminology. It would be clearer, and easier to understand, to simply state that alpha <= 128 is transparent, or that alpha > 128 is opaque in LOD.

Thanks.