DynDOLOD 3.00 Alpha 180

[DoubleYou]

35 minutes ago, mooit said:

You showed me before that the best way was to use 1.0 for all the settings, then adjust the Direct/Ambient in TexGen, which I've been using for the grass; Direct 50 Ambient 5.

 

; grass LOD brightness multipliers
GrassBrightnessTopR=1.0
GrassBrightnessTopG=1.0
GrassBrightnessTopB=1.0
; make bottom darker to fake shadowing
GrassBrightnessBottomR=1.0
GrassBrightnessBottomG=1.0
GrassBrightnessBottomB=1.0

 

 

Yeah, I believe @z929669 is mistakenly linking to older settings he was using before more of our in-depth testing.

[mooit]

35 minutes ago, DoubleYou said:

Yeah, I believe @z929669 is mistakenly linking to older settings he was using before more of our in-depth testing.

Ok, I re edited the post, look at what I mentioned about height and angle when looking at grass, this is the biggest area of problem I'm trying to tackle. When standing up high, looking down and out at the grass closeup and far away, having a better match.

THANKS

[mooit]

On 8/25/2022 at 7:56 AM, sheson said:

The settings affect all (alpha) textures on the object LOD or tree LOD atlas.

1. is explained by reading the explanations above the setting. AlphaCoverage is used if texconv is used to generate mipmaps. AlphaFactor is used for the internal mipmap generation
2. AlphaCoverage = texconv command line argument -keepcoverage, AlphaFactor = factor used for internal or internal alpha-to-coverage scaled algorithm.

Instead of changing these values here, I suggest to change the alpha threshold of the 3D tree LOD model. It will have direct impact on the texture and mipmap when the full texture added to the atlas. Think of it as the initial setting for the first mipmap with the highest resolution from which all other mipmaps with lower resolution are derived.

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. Again, note that the UV texture coordinates need to be >= 0.0 and <= 1.0 for LOD being able to use the atlas texture. If the UV is outside those limits, LOD will use the texture directly.

Sorry for being dense here, where do you change this Alpha Threshold at?

It was suggested to me, to just reduce the AlphaFactor, to try this, to see if Happy Little Trees might look a little better detailed in the distance.

But I noticed shenson mentioning to change the Alpha Threshold instead.

I've been reading around, I don't see, or understand where, if someone could be so kind as to just tell me what to adjust is all?

THANKS

Edited August 27, 2022 by mooit

[z929669]

2 hours ago, DoubleYou said:

Yeah, I believe @z929669 is mistakenly linking to older settings he was using before more of our in-depth testing.

I meant this post. sorry.

[z929669]

2 hours ago, DoubleYou said:

No alterations to the normal texture besides resizing to 128 for the 128 size tests was performed. This is for consistency, as I want to only highlight the alpha transparency tree leaf issues for this set of tests to show how they affect the tree here.

Tree mod is Aspen's Ablaze, Autumnal version. Tree LODs were made based on the 0.1 meshes on the Aspen's Ablaze DynDOLOD Addon page. I have not checked to see what @z929669 has done with the other two versions as of yet, but I don't believe there is much deviation other than alteration of textures.

Videos:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

 

Screens:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

   

 

Map color issue:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

   

 

Logs:

Full Texture, NiAlphaProperty 128: https://mega.nz/file/sVpQQIQI#QDBge9xU5H1Hd1VrBrkRkUTHxzNYGp6IVuIbbrefxpw

Full Texture, NiAlphaProperty 224: https://mega.nz/file/ZBZEyZhK#TtlLb9dqNALK5GSAZbSSj36OqkJSXNCMcnBv5hVfQGQ

128 Texture, NiAlphaProperty 128: https://mega.nz/file/oUQgkSyA#i4iQqgj581fOlaL7j2eE6wttheMT1QMxD-CWPstrt5I

128 Texture, NiAlphaProperty 224: https://mega.nz/file/cZI0EZAS#usFfKTc1VYs3qYfMKEFpwgpcskJma2bwML0Hgq0ARTw

 

My Conclusions:

Thresholding the 4k texture does not appear to provide enough alpha transparency for trees. Instead, the only apparent change is to color, which is only affecting some of the trees. My current belief is that is the tree with the errant Specular flag in the full model, and also the LOD model. I hadn't noticed this color change in previous testing, but given the discussions above, I made a point to look for it. This is best seen in screens 1 and 2.

Looking at the alpha transitions in the videos, the trees are just as thick with NiAlphaProperty set to 224 as it is set to 128. This is the main thing I want to tighten up, as the trees look very blocky due to the thicker alpha.

Also notice that the full texture suffers from a problem on the map where the texture changes from orange to red as you zoom out.

Next, I resized the texture via Paint.NET to 128 size, using SuperSampling as the method of scaling. Naturally, since scaling removes the amount of pixels, more pixels are semi-transparent, and therefore, more effectively manipulated via alpha threshold settings. You can clearly see this in that the 128 size texture itself is nearly, although not perfectly, a match for the transition in the video, alpha wise. Obviously, 224 threshold is given for completeness and to display that changing it clearly affects the result to a much greater degree.

The 128 textures on the map is more resistant to the color change, but is turning more desaturated on the map. I will provide information on the fix for this later, as this is the reasoning behind the normal map changes that I have briefly mentioned.

There are other little nuances about these very simple changes that can be noticed as well, but the main focus of this compare is the alpha transparency.

Thanks for this. In all of my testing, I suppose it's possible I mucked something up in one of my iterations. Back to the drawing board to reproduce on my end.

[sheson]

8 hours ago, z929669 said:

I set things up to test in a single run due to your suggestion to change NiAlphaProperty of specific aspen LOD models rather than all at once. This way, I should see a mix of the LOD trees I want to examine:

1. Treeaspen01 - NiAlphaProperty=128, textures=birch03_c.dds, birch03_n.dds (4k)
2. Treeaspen02 - NiAlphaProperty=224, textures=birch03_c.dds, birch03_n.dds (4k)
3. Treeaspen03 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
4. Treeaspen04 - NiAlphaProperty=224, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
5. Treeaspen05 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
6. Treeaspen06 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
7. Treeaspen07 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
8. Treeaspen08 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)
9. Treeaspen09 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px)

To confirm the above, these are the LOD meshes used for this run: meshes.7z

The texture appears 3x on the atlas (I'm not uncertain about the second line even though you attempted to explain). I also don't understand which is associated with what NiAlphaProperty. I expected two versions for each texture corresponding to the test list above (four scenarios). Is something off here?:

textures\mx\birch03_c.dds,textures\mx\birch03_n.dds	256	256	12032	3840	Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds	16384	8192
textures\mx\birch03_c.dds,textures\mx\birch03_n.dds=14	256	256	11776	3840	Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds	16384	8192
textures\mx\birch03_c_lod.dds,textures\mx\birch03_lod_n.dds	128	128	13328	4096	Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds	16384	8192

Here's the three cutouts from the atlas saved as TGA so you can see the alphas (they are pretty similar):

aspenAtlasCutouts.7z 73.99 kB · 3 downloads

 

Do not use "lod" in the name of textures if you want them to be treated like full textures being downsized and adjusted for the object LOD atlas.

I would be interested in directly comparing the actual texture of the 4k input to 256 input and if 4k has no change or just a very small change in the alpha channel. Use pipette to get the alpha value of a pixel.

So, with this we know that the 4k input has an alpha change that is ever so slightly making things thinner. Looking forward to the 256 pixel input to compare to.

Also upload the 256 input textures again together with the output so I do not have to wonder I got the right one from earlier posts.

[sheson]

5 hours ago, DoubleYou said:

No alterations to the normal texture besides resizing to 128 for the 128 size tests was performed. This is for consistency, as I want to only highlight the alpha transparency tree leaf issues for this set of tests to show how they affect the tree here.

Tree mod is Aspen's Ablaze, Autumnal version. Tree LODs were made based on the 0.1 meshes on the Aspen's Ablaze DynDOLOD Addon page. I have not checked to see what @z929669 has done with the other two versions as of yet, but I don't believe there is much deviation other than alteration of textures.

Videos:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

 

Screens:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

   

 

Map color issue:

Full Texture, NiAlphaProperty 128 --> Full Texture, NiAlphaProperty 224 --> 128 Texture, NiAlphaProperty 128 --> 128 Texture, NiAlphaProperty 224

   

 

Logs:

Full Texture, NiAlphaProperty 128: https://mega.nz/file/sVpQQIQI#QDBge9xU5H1Hd1VrBrkRkUTHxzNYGp6IVuIbbrefxpw

Full Texture, NiAlphaProperty 224: https://mega.nz/file/ZBZEyZhK#TtlLb9dqNALK5GSAZbSSj36OqkJSXNCMcnBv5hVfQGQ

128 Texture, NiAlphaProperty 128: https://mega.nz/file/oUQgkSyA#i4iQqgj581fOlaL7j2eE6wttheMT1QMxD-CWPstrt5I

128 Texture, NiAlphaProperty 224: https://mega.nz/file/cZI0EZAS#usFfKTc1VYs3qYfMKEFpwgpcskJma2bwML0Hgq0ARTw

 

My Conclusions:

Thresholding the 4k texture does not appear to provide enough alpha transparency for trees. Instead, the only apparent change is to color, which is only affecting some of the trees. My current belief is that is the tree with the errant Specular flag in the full model, and also the LOD model. I hadn't noticed this color change in previous testing, but given the discussions above, I made a point to look for it. This is best seen in screens 1 and 2.

Looking at the alpha transitions in the videos, the trees are just as thick with NiAlphaProperty set to 224 as it is set to 128. This is the main thing I want to tighten up, as the trees look very blocky due to the thicker alpha.

Also notice that the full texture suffers from a problem on the map where the texture changes from orange to red as you zoom out.

Next, I resized the texture via Paint.NET to 128 size, using SuperSampling as the method of scaling. Naturally, since scaling removes the amount of pixels, more pixels are semi-transparent, and therefore, more effectively manipulated via alpha threshold settings. You can clearly see this in that the 128 size texture itself is nearly, although not perfectly, a match for the transition in the video, alpha wise. Obviously, 224 threshold is given for completeness and to display that changing it clearly affects the result to a much greater degree.

The 128 textures on the map is more resistant to the color change, but is turning more desaturated on the map. I will provide information on the fix for this later, as this is the reasoning behind the normal map changes that I have briefly mentioned.

There are other little nuances about these very simple changes that can be noticed as well, but the main focus of this compare is the alpha transparency.

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.

[sheson]

4 hours ago, mooit said:

Sorry for being dense here, where do you change this Alpha Threshold at?

It was suggested to me, to just reduce the AlphaFactor, to try this, to see if Happy Little Trees might look a little better detailed in the distance.

But I noticed shenson mentioning to change the Alpha Threshold instead.

I've been reading around, I don't see, or understand where, if someone could be so kind as to just tell me what to adjust is all?

THANKS

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.

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