sheson

We determined that the order of when the threshold adjustment is done needs to be after the mipmaps are created and not before that so it has the desired results. Normal map textures do not contain alpha information that is used for alpha blending/testing with the standard shaders. The alpha information is in the diffuse texture. What you see is that DynDOLOD is creating mipmaps differently to how the mipmaps of the full texture were created. You could say the alpha of the mipmaps of the full textures are too thin. Either way, they do not match perfectly. We know this can happen, hence the suggestion for the threshold adjustment in the LOD model. Now that people know how to create mipmaps with alpha-to-coverage, I'll add a shape name command so a LOD model can instruct to keep using the mipmaps from the source texture instead of generating them.

Unfortunately you started DynDOLOD one more time after generating, which replaces the debug log, so I do not have any of its information from the generation. Nevertheless, if your load order and settings cause DynDOLOD to run several hours and produce 10s of GB of output you are obviously overdoing/putting too much stuff into LOD. Really read the documentation, for example: https://dyndolod.info/Help/Grass-LOD#Settings Change the Density dropdown to a lower value in the advanced mode of DynDOLOD under the Grass LOD checkbox to thin out grass LOD for better performance. In case the grass pre-cache was generated with SuperDenseGrass = True, expect really long object LOD generation times. Lower the density to 33% or less. https://dyndolod.info/Help/Grass-LOD#Performance https://dyndolod.info/Help/Grass-LOD#Troubleshooting, especially the parts about out of memory. Also https://dyndolod.info/FAQ DynDOLOD/TexGen Questions - High memory usage / Out of memory

It's just the filename. The threshold it was created with was 224.

Thanks. I will need to look at this some more in the coming days. I still would expect it to match better. The 244_new.dds seems to be dull compared to the 128.dds with 224 NiAlphaProperty for some reason and that doesn't seem right with me why that would even be the case.

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.

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?

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.

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.

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.

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

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.

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.

This looks like an object distance setting fading in/out the waterwheel. Something similar to what is explained in ../DynDOLOD/Docs/DynDOLOD_Manual.html "Glow LOD" or one of these https://stepmodifications.org/wiki/Guide:Skyrim_INI/LOD DynDOLOD enables/disable objects when crossing cell borders. It does typically not work with tcl as it uses trigger boxes. Check the enable/disabled status of the reference in the more informative console information when it is visible / not visible. If it also shows "Is Enabled: Yes" for the reference while it is not visible, then it was not DynDOLOD that made the waterwheel disappear.

Why are you changing mesh mask rules that are known to work as desired for over half a decade? IIRC there is no such suggestion in the FAQ answers.

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.

Read answers for FAQ: Game: Out of place objects / floating objects / flickering full models in ..\DynDOLOD\Docs\DynDOLOD-FAQ.txt Follow their suggestions.

Define 2 meters. It seems a bit exaggerated. Read answers for FAQ: Game: Out of place objects / floating objects / flickering full models in ..\DynDOLOD\Docs\DynDOLOD-FAQ.txt

https://dyndolod.info/How-LOD-Works https://dyndolod.info/Help/Object-LOD#Settings https://dyndolod.info/Help/Tree-LOD#Settings https://dyndolod.info/Help/Terrain-LOD#Settings https://dyndolod.info/Help/Mod-Configuration-Menu#Settings I can guarantee that these settings control how far LOD (Levels) are shown and changing them has an immediate visible effect how far LOD (levels) show in the game.

The screenshots only show if there is a difference or not. I can not tell what is supposed to match better or look better. I have no idea what screenshots are supposed to show "washed out" textures. How are they washed out? Do they loose color? What I can say is this: screenshot #1 and #2 have clearly different tree LOD. Can fog only affect tree LOD? So far the screenshots and the different statements are just more confusing to me than being helpful. In part because I probably need to see and move the camera in game myself. Lets forget for a moment how things look in the game and really check the textures. Get a feel how changing the threshold from 128 to 244 actually affects how the model/leaves looks in NifSkope. Then compare the textures added to the texture atlas. As long as you do not change the threshold of all 3D tree LOD models, the diffuse texture should be added to the object LOD atlas texture at least twice, once for the 128 threshold and once for the 224 for example. You can find their pixel coordinates in..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt. The threshold is divided by 16 and part of the first column in case it is not the default of 128. So there are two rows for the texture with their different coordinates on the atlas textures\mx\birch03_c.dds,textures\mx\birch03_n.dds ... textures\mx\birch03_c.dds,textures\mx\birch03_n.dds=14 ... If you use an image program to cut those textures out of the atlas you can then directly compare their alpha channels side by side or by switching back and forth to see if they are different and by how much. I would be interested in directly;y comparing the actual texture 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. If changing the alpha threshold has a stronger effect on smaller source textures, then it means a step might be missing in the processes or maybe something is done on the wrong order.

There is clearly a visual difference between the tree LOD of screenshot #1 and #2 which were made the 4k source textures if I am not mistaken. If the only change is the alpha threshold, then this is the result of the increased transparency. DoubleYou reported "no observable difference" however. The screenshots #3 and #4 made with the resized texture seem to be more or less the same, despite the change in the threshold. DoubleYou reported "way too thin" for the 224 threshold with 256 pixel texture, which would be the expected result when increasing the threshold. I do not know what blotchy alpha is supposed to look like. Wasn't the goal to have less transparency so the leaves appear to be thicker when further away? "Bleeding" means neighborly pixels affect each other. Which happens when shrinking. The alpha information should not cause bleeding of color, unless you mean if something is more transparent, something behind it shines through.

There are differences between image #1 (left) and #2 and #3? #3 and #4 (right) seem close. Could the order be reversed? Which screenshot or LOD version is the one where you believe LOD matches the full trees best? Not what seems to look best in a still, what has the least noticeable switch between LOD / full model? When you say diffuse just resize, how? Upload it. Normal map texture does not matter.

Read the first post which log and debug log to upload when making posts. The settings show you opted to use Billboard4 for the first LOD Level 4 for the "tree" mesh mask rule. Read https://dyndolod.info/Help/Ultra-Tree-LOD to learn how to generate LOD for trees with 3D tree LOD models and its requirements, e.g. download/create 3D tree LOD models and set LOD Level 4 to Level0 in order to use the 3D tree LOD models.

Only one session with a threshold that is not anywhere near 128 not having an affect on the texture on the object LOD atlas is required. The texture in question is one of birch03_c.dds, birch03g_c.dds or birch03y_c.dds? How do you check/compare the generated object LOD atlas texture and its mipmaps? Normal map textures have no effect on diffuse alpha. The 4th channel of normal map textures is typically used for the specular map.

Upload log and debug log and provide example files required to reproduce the problem. Existing mipmaps in full textures are irrelevant and can not reliably be used - we learned that many years ago. The tools load the largest resolution of a textures, DynDOLOD applies the alpha threshold adjustment and the mipmaps are build from them. The alpha threshold adjustment should always be applied. The generated mipmaps should always have alpha-to-coverage applied. It's possible if a texture is too large there is an (automatic) resize step somewhere that forgets required alpha treatment.

Do not use texconv to generate mipmap for the LOD atlasses. It is the inferior method and will cause mipmap artifacts. A tree LOD texture atlas for which the TreeLODGenerateMipMaps is used and only created when generating standard tree LOD. Ultra tree LOD is LOD for trees done in object LOD, so the ObjectLODGenerateMipMaps applies. The alpha threshold of LOD is fixed to 128 and can not be changed. As explained in the documentation, the alpha threshold from LOD models is used to adjust the texture of the first mipmap / largest resolution of the texture. The mipmaps with lower resolution are derived from this adjusted texture and their alpha adjusted with the AlphaFactor. 0.25 (1/4) is the actual reduction of the resolution for each mipmap. It is the correct value. 3D tree LOD models (and any other other LOD model with alpha) included in DynDOLOD Resources SE expects this value. It also works correctly with the billboards added to the standard tree LOD atlas. Adjusting the alpha threshold in the NIF is the documented method to control "thickness" of alpha textures for ultra tree LOD since many years.