DynDOLOD 3.00 Alpha 196

[mooit]

1 hour ago, sheson said:

https://dyndolod.info/Help/3D-Tree-LOD-Model
"DynDOLOD reads the alpha threshold from the NiAlphaProperty from the models used for LOD"

It refers to the NIF model used for LOD. Read the linked documentation.

I read that before, I still don't understand where the adjustments are made, do you have to adjust this in nifskope?

THANKS

 

4 hours ago, z929669 said:

I meant this post. sorry.

 

Ok, THANKS

Edited August 27, 2022 by mooit

[sheson]

1 hour ago, mooit said:

I read that before, I still don't understand where the adjustments are made, do you have to adjust this in nifskope?

Use whatever tool that allows editing of NIF models. NifSkope seems like the obvious choice.

If you read https://dyndolod.info/Help/3D-Tree-LOD-Model you would see screenshots from NifSkope that show the NiAlphaProperty blocks as children of the BSTriShape blocks.

https://www.google.com/search?q=NIF+model+NiAlphaProperty
->
http://wiki.beyondskyrim.org/wiki/Arcane_University:NIF_Data_Format#Transparency

[DoubleYou]

5 hours ago, sheson said:

Those screenshots are interesting. Still would prefer the actual input/output textures to directly compare in an image program.

"the only apparent change is to color"
Alpha threshold adjustment / mipmapping of the diffuse textures does not directly change color of textures. Whatever effects you see in the game has typically to do with the pixels that were more opaque. Specular is typically no showing very far away. Brightness is changed if the normal map is different or if the CrownBrightness DynDOLOD INI settings is not 1 anymore. If textures are not R8B8G8A8, compression artifacts may have a slight affect on color of pixels.

"Naturally, since scaling removes the amount of pixels, more pixels are semi-transparent, and therefore, more effectively manipulated via alpha threshold settings"
There are 1/4 of the pixels each time you divide resolution by 2. There should be considerably less pixels that are not fully transparent or fully opaque. Using alpha-to-coverage downsizing is is typically used to make sure the percentage does not change. The threshold adjustment is multiplying all alpha values of all pixels of a texture. It "effectiveness" does not change.

The only thing that is really relevant to me is, that the alpha threshold is supposed to have the same effect on textures regardless their input size.
However, if you shrink the 4k texture to 256 or 128 you use a different alpha-to-coverage method - if at all.

For me to be able to check I need the actual input/output textures so I can compare the adjusted output textures used by 128 threshold models with models that uses the not adjusted input texture with a 224 threshold - first mipmap only. Those are supposed to look similar in the end.

I agree that the color change is likely caused by the threshold change, since 224 is an extremely high threshold setting. The main point I am trying to make here is that changing the threshold of the NIF utilizing the full texture is not a viable way to control the alpha thickness of the resultant texture on the atlas, and redirection to a custom texture seems to be absolutely necessary to ensure a more closely matching alpha transparency to prevent pop in.

I goofed on this compare for the 128 size texture in saving as BC7. So many variables I'm trying to control to give the perfect test! Here is the 128 size textures used, and the full textures used: https://mega.nz/file/0NoRBZbL#sBLHpI3jO-UjbTIba5buM2axMZ7AkkBiSfoR9DcSkVE

 

[sheson]

1 hour ago, DoubleYou said:

I agree that the color change is likely caused by the threshold change, since 224 is an extremely high threshold setting. The main point I am trying to make here is that changing the threshold of the NIF utilizing the full texture is not a viable way to control the alpha thickness of the resultant texture on the atlas, and redirection to a custom texture seems to be absolutely necessary to ensure a more closely matching alpha transparency to prevent pop in.

I goofed on this compare for the 128 size texture in saving as BC7. So many variables I'm trying to control to give the perfect test! Here is the 128 size textures used, and the full textures used: https://mega.nz/file/0NoRBZbL#sBLHpI3jO-UjbTIba5buM2axMZ7AkkBiSfoR9DcSkVE

I suggest to compare 2 identical full model trees that only have different threshold values next to each other at varying distances. To get an idea what actually happens by that change alone.

[DoubleYou]

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224, no specular on TreeAspen01 --> Full Texture, NiAlphaProperty 224

   

It turns out I was correct that the errant specular on TreeAspen01 was causing most of the hue shift with the higher NiAlphaProperty.

[DoubleYou]

1 hour ago, sheson said:

I suggest to compare 2 identical full model trees that only have different threshold values next to each other at varying distances. To get an idea what actually happens by that change alone.

I am uncertain what exactly your suggested test is here? If comparing the change within uGridsToLoad, the alpha change in the NIF is going to affect each individual mip by itself, so it is not going to mimic the LOD texture creation exactly, since it only considers the top mip, applying the NiAlphaProperty threshold to that, and then generating mipmaps via fixed threshold after that, which produces the too thick alpha that we are experiencing.

[sheson]

45 minutes ago, DoubleYou said:

I am uncertain what exactly your suggested test is here? If comparing the change within uGridsToLoad, the alpha change in the NIF is going to affect each individual mip by itself, so it is not going to mimic the LOD texture creation exactly, since it only considers the top mip, applying the NiAlphaProperty threshold to that, and then generating mipmaps via fixed threshold after that, which produces the too thick alpha that we are experiencing.

We will want to see what really happens with that change alone to the full model - to see if it only affects thickness or anyhting else as well. It will also help to see if changing the order of things for the LOD texture generation matches it better, especially regarding  any brightness or color changes:

https://mega.nz/file/YUJ1DJYZ#T15015iz9xJjcNN6fR3SHq0IHuI9S9dVj5MrhlYTmIs

128.dds = generate mipmaps from 4k texture.
224_old.dds = adjust alpha of 4k texture, generate mipmaps from that.
224_new.dds = generate mipmaps from 4k texture, adjust alpha for each mipmap.

Compare the alpha of the 512 or 256 mipmap resolution. "new" order looks quite thinner, so that seems more like what we want.

[DoubleYou]

37 minutes ago, sheson said:

We will want to see what really happens with that change alone to the full model - to see if it only affects thickness or anyhting else as well. It will also help to see if changing the order of things for the LOD texture generation matches it better:

https://mega.nz/file/YUJ1DJYZ#T15015iz9xJjcNN6fR3SHq0IHuI9S9dVj5MrhlYTmIs

128.dds = generate mipmaps from 4k texture.
224_old.dds = adjust alpha of 4k texture, generate mipmaps from that.
224_new.dds = generate mipmaps from 4k texture, adjust alpha for each mipmap.

Compare the alpha of the 512 or 256 mipmap resolution. new looks quite thinner, so that seems what we want.

I think I understand now. Let me look into this.

[DoubleYou]

It appears that PostImages.org is down right now, so I will directly attach.

So hopefully this is what you were wanting to see:

Original texture from mod --> 244_new.dds --> 244_old.dds --> 128.dds

 

BTW, I used TLL console command to ensure everything is full trees. This is very close, but slightly less alpha. If I were to guess, you numbers are varying NiAlphaProperty thresholds, so this should be able to be adjusted via this method.

[sheson]

1 hour ago, DoubleYou said:

It appears that PostImages.org is down right now, so I will directly attach.

So hopefully this is what you were wanting to see:

Original texture from mod --> 244_new.dds --> 244_old.dds --> 128.dds

 

BTW, I used TLL console command to ensure everything is full trees. This is very close, but slightly less alpha. If I were to guess, you numbers are varying NiAlphaProperty thresholds, so this should be able to be adjusted via this method.

What is the difference between the upper 4 screenshots and the lower 4 screenshots?

The alpha value of all mipmaps is multiplied by the same 128/threshold factor = 0.5714 in this case.

[DoubleYou]

The upper screenshots are farther away. The lower screenshots are closer. 

[sheson]

54 minutes ago, DoubleYou said:

The upper screenshots are farther away. The lower screenshots are closer. 

So the last two of each row. The 224_old.dds is with a 128 threshold NiAlphaProperty and the 128.dds is with a 244 threshold NiAlphaProperty?

[DoubleYou]

40 minutes ago, sheson said:

So the last two of each row. The 224_old.dds is with a 128 threshold NiAlphaProperty and the 128.dds is with a 244 threshold NiAlphaProperty?

I left NiAlphaProperty at 128 for all tests. I simply changed out the full texture with the provided texture in each case. Let me audit my screenshots to ensure that I have this in the right order. I think I mixed up the first two somehow...

Edit:

Okay, so I evidently mixed up 1 and 2 in each set.

Original texture from mod --> 244_new.dds --> 244_old.dds --> 128.dds

[sheson]

36 minutes ago, DoubleYou said:

I left NiAlphaProperty at 128 for all tests. I simply changed out the full texture with the provided texture in each case. Let me audit my screenshots to ensure that I have this in the right order. I think I mixed up the first two somehow.

The models that use the orginal/not adjusted texture 128.dds should have an alpha threshold of 224, while the models that use adjusted 224_* textures should have an alpha property of 128 - the one LOD is hardcoded to use.

[DoubleYou]

34 minutes ago, sheson said:

The models that use the orginal/not adjusted texture 128.dds should have an alpha threshold of 224, while the models that use adjusted 224_* textures should have an alpha property of 128 - the one LOD is hardcoded to use.

Okay. Let me get this for you. Please see my edit though, as I mixed up 1 and 2 in my previous post accidentally.