sheson

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log, debug log and LODGen logs to upload when making posts. Obviously also upload the combine.txt.

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 make useful before/after screenshots with more informative console. Use Mfg Console or More Informative Console to show additional information when opening the console and clicking an object. If making screenshots of objects missing with DynDOLOD output enabled, make a screenshot of the objects as explained above without DynDOLOD output enabled. "I don't know how to do the rest." Not sure what "rest" applies to. If you need help with something, ask a specific question.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log an debug to upload when making posts. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful before/after screenshots with more informative console.

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

Thanks. This should be fixed in Alpha-150.

The old error was: Error: Access violation at address 0000000001203EBE in module 'DynDOLODx64.exe'. Read of address 0000000000000000. This time it is a completely different error and message: Error: Load order FileID [19] can not be mapped to file FileID for file "DynDOLOD.esp" See what happens with this test version https://mega.nz/file/xE4ljRBQ#YE5UsWJom55oK3DIpoYfdbyrrGGTdD0NUf_11LmPRjs If there is still an issue new or old, post new log, debug log and bugreport.txt

Great! Thanks for letting us know.

See if this test version works https://mega.nz/file/ZNpwFIyI#6igo_GD5JrsFuPPDFZyUNYV88LP1iKycqCmvzOSwijU if not upload new log, debug log and bugreport.txt

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how zip and upload the entire debug log to a file service and also bugreport.txt if it exists when making posts.

This is about complex grass being split into diffuse and normal map without mipmaps and the OpenGL texture loader not generating mipmaps as texture loading did. The darkness of that automatic mipmap generation probably comes from the black transparent background of some of the complex grass textures. Get this test version https://mega.nz/file/4VAQ2ICZ#DmIshNshEeFj2u2uHOQEYBtdaJfmqGqK8KcjpmL23Ms. The OpenGL loader will now generate mipmaps, too and so the rendered billboards should now have the same brightness as before. If they are still very different let me know.

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.

You seem to be reporting that TexGen generates brighter grass billboard textures for some grass models/textures but not for others. TexGen should always be using the same direct and ambient lighting settings for all grass billboards it generates, so they all should have the same brightness. Use the Preview button next to the HD grass billboards to check their visuals. If there is a difference between models/textures from BSA and loose files it should be obvious in either the diffuse or normal preview. If that is the case provide screenshots of two different textures that show the difference. If there is no difference in the preview, check the actual generated grass LOD billboard dds textures in the TexGen output folder. In that case upload two textures that show the difference.

Does that mean the issue is resolved?

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. The games 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 hardcoded to be greater than, unless in Fallout 4. 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. As in read the alpha value from texture, change it, write alpha value to the texture. Alpha-to-coverage algorithms multiply alpha values with a factor. 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.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug to upload when making posts. From the first post: Always use the latest alpha version. Do not waste time using older versions or reporting problems with older versions. https://dyndolod.info Always use the latest version. Using the latest version and providing feedback or reporting problems is a requirement to participate in the alpha test. Do not waste time using older versions or reporting problems with older versions. Participating in the alpha test requires to report any problems to the official DynDOLOD support forum. https://dyndolod.info/Help/TexGen#Direct-Ambient-Smoothness

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. 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. Yes, as explained, this is what the game does, default threshold of 128 and greater than alpha test function. 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.

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 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. 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. Rule of three. We have old alpha value, old threshold and new threshold. 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.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs and/or my signature how to use a file service to upload large files.

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

The object LOD atlas texture - in particular the one I requested from the user together with the txt from the DyNDOLOD export folder - was part of the DynDOLOD output. Read the posts what was troubleshooted and what files I requested in addition to the logs.

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 of "UseMipMaps" in this paragraph. That means it has no effect on adjusting the alpha to work with the hardcoded alpha threshold. 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. To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames. 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. Logic dictates that if the alpha channel needs to be adjusted, it always happens to all mipmap levels regardless their source.

No. I do not not. As I said, leave the shader settings as the full model. They should not be adjusted. Do not invent unnecessary or counter productive steps. The LOD model should work exactly like the full model when being used in the game directly. "The billboards you have were generated by TexGen, so they are good to use as is." <- That means the mipmap artefact was not caused by third party billboards. "This is about billboard placements on the atlas texture." <- That means, the placement of a billboard next to another texture on the object LOD atlas texture caused the mipmap artefact. The solution was to fix how billboards are placed on the texture atlas.

The threshold value is used to adjust (e.g. multiply with the factor) the alpha channel of the source texture so that it still looks the same with the default alpha threshold of 128. As already mentioned earlier, the alpha test function of LOD uses greater than, just as the default NiAlphaProperty. Exact values only really matter with uncompressed textures and if manually crafting an alpha channel that for a strange reason relies on the difference of 1 byte or 0.004 only to decide if a pixel should be transparent or not. If you need to control specific pixels exactly, use 0 and 255. 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. 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 These are two different things.

This is about billboard placements on the atlas texture. The billboards you have were generated by TexGen, so they are good to use as is.

Leave the shader settings as the full model. If any of the settings causes issues in LOD because it slips through, report it.