DynDOLOD 3.00 Alpha 173

[z929669]

On 8/28/2022 at 10:16 AM, z929669 said:

Finally got around to repeating my tests. This time, I succeeded in reproducing @DoubleYou's result.

I removed the Specular flag from the source AA treeaspen01 model and set Glossiness to 80 to make it consistent with treeaspen02-09.

In my testing, I either use the AA 4k source texture or a 256px version of that taken from that mip level of the 4k texture to use as a LOD-specific version (named as "autumnal.dds" rather than "birch03_c_lod.dds" per sheson's advice to remove "_lod" from the file name). This way, the source alpha of my 256px texture is direct from source without any resizing artifacts. This LOD specific texture was saved without mips, since DynDOLOD only needs the top level.

I also used a version of the AA 4k source normal WITHOUT alpha and the 256px mip from that as Source for LOD-specific normals (also saved without mips). See source normals.

1. Full AA source texture, NiAlphaProperty=128 - logs
2. Full AA source texture, NiAlphaProperty=224 - logs
3. 256 mip source texture, NiAlphaProperty=128 - logs
4. 256 mip source texture, NiAlphaProperty=224 - logs

DynDOLOD is definitely making a thicker alpha when processing the full AA texture. Check out the alpha of the source against the DynDOLOD renditions snipped from the respective atlas of each run. I have labeled then in an obvious way as indicated above --> z-tests.7z

1. 0 source-256 mip.dds (source used for #3 & #4 tests above)
2. full-128.tga (#1 test starting with 4k AA source texture)
3. full-224.tga (#2 test starting with 4k AA source texture)
4. 256-128.tga (#3 test starting with 256px mip of AA source texture)
5. 256-224.tga (#4 test starting with 256px mip of AA source texture)

So I stand corrected in that NiAlphaProperty changes do have impact, but only marginally when the source texture is 4k. The impact is much closer to expected when the source texture is smaller resolution.

From the screens, the #3 test produces the best transitions in game (which is great, because ideally, I don't want to customize NiAlphaProperty). In a perfect world, DynDOLOD produces a LOD version on the atlas that more closely approximates or exactly matches the 256 mip alpha of the source 4k texture.

 

On 8/28/2022 at 3:17 PM, sheson said:

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.

Testing the aspens again using the latest alpha 96 ...

The first screen is as I indicate above in test case #4 above (this is what is configured in the AA DynDOLOD Add-On mod (performance, autumnal). The second screen is using the same models exactly but referencing the original AA diffuse rather than the special version I created from the 256 mip of the original (saved this without mips).

I think the result is improved, but branches are still a bit too thick. I assume this is due to the alpha opacity of the original AA branch texture mips?

Logs corresponding to the second image: https://mega.nz/file/ecNmBCLQ#hQaAlvfWtH9h7NDZXvP_n39i0gmJP8bhpYrOgiNdk_k

[DoubleYou]

@z929669

See this addition to the documentation with the update:

I think we want to try that UseMipMaps thing he added.

[z929669]

1 hour ago, DoubleYou said:

@z929669

See this addition to the documentation with the update:

I think we want to try that UseMipMaps thing he added.

Thanks, I missed that. I was hoping we could do it without manipulating the models, but I will do this tomorrow and update.

[sheson]

3 hours ago, z929669 said:

FYI. Alpha 96 is working without issue for me. TexGen takes about 20% longer (from 100s in alpha 95 to 125s in alpha 96 [Step SSE mod list, same exact LO as always]), and DynDOLOD processing time is normal. The new complex grass shows some real promise in my initial runs. I am using DynDOLOD grass tints normalized to 1.000 for all top/bottom and TexGen HD grass Direct/Indirect 0/145 in this example (Direct seems to have no impact on HD grass). Running again at 0/155 and will test more stuff  after.

EDIT: I have noticed that LOD4 grass seems to show as a slightly darker band than LOD8 and greater ... again, nothing definitive at this point. Just a casual observation as I search for the best TexGen settings for our setup.

The default TexGen setting make textures a bit brighter, so the brightness INI settings can stay under 1.0 in case a user needs to brighten a color channel.

Grass LOD is done in object LOD 4 only, which means all grass LOD uses the same normals and shader settings at all times. The "interesting" time of day is dawn and dusk, when one side it lit and the other side is dark. Full grass uses a different shader than the (also limited) LOD shader, so there will always be some difference in behavior.

2 hours ago, z929669 said:

 

Testing the aspens again using the latest alpha 96 ...

The first screen is as I indicate above in test case #4 above (this is what is configured in the AA DynDOLOD Add-On mod (performance, autumnal). The second screen is using the same models exactly but referencing the original AA diffuse rather than the special version I created from the 256 mip of the original (saved this without mips).

I think the result is improved, but branches are still a bit too thick. I assume this is due to the alpha opacity of the original AA branch texture mips?

Logs corresponding to the second image: https://mega.nz/file/ecNmBCLQ#hQaAlvfWtH9h7NDZXvP_n39i0gmJP8bhpYrOgiNdk_k

Use the same texture as the full model.

Then, if LOD seems to thick, increase the threshold of the LOD model in steps of 16 (it should now have stronger impact since it is now applied after generating mipmaps).

Or instruct to use the mipmaps from the source texture. See https://dyndolod.info/Help/3D-Tree-LOD-Model
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 done for all LOD models using this texture. Use an unique filenames for such textures, so there are no problems with other mods modifying the same vanilla filenames.

[sheson]

@Thekittymix @Jakolanten @TeostraAscend @Eliian

Read the first post which log and debug log to upload when making posts.

[sheson]

3 hours ago, Eumeta said:

Hi sheson, I got a bug report of the new version Alpha 96, Dyndolod 3 stopped running ( still running as application but zero progress from 100% CPU usage to nil at the beginning of Tamriel object LOD generation). This did not happen in previous versions.
Attached are the bug report and the log, the debug log is too large to insert so i'm putting a link instead. https://drive.google.com/file/d/1JuNF3um-BHtxem6xDJsTWwYhhwPPl9po/view?usp=sharing . Thank you.

bugreport.txt 143.05 kB · 1 download DynDOLOD_SSE_log.txt 2.3 MB · 1 download

Form the log:

[00:27] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Better Dynamic Snow.esp NorTentLargeSnow [STAT:000EA068]>
[02:56] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Meshes\architecture\tents\largenordictent01.nif Skyrim.esm NorTentLarge [STAT:000800DE]>
[02:56] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Skyrim.esm NorTentLarge [STAT:000800DE]>
[06:39] <Error: File not found textures\clutter\common\ruground02_n.dds>

It seems a mod is missing a texture or a requirement. Check which mod contains textures\clutter\common\ruground02.dds as that should also have textures\clutter\common\ruground02_n.dds

[sheson]

7 hours ago, Akidson said:

Hello, I am encountering crashing in the area around Ivarstead. Here are the crash logs:

Crash_2022_9_13_1-27-18.txt 94.39 kB · 4 downloads Crash_2022_9_13_1-33-23.txt 94.43 kB · 3 downloads Crash_2022_9_13_1-38-53.txt 97.49 kB · 1 download Crash_2022_9_13_2-2-15.txt 91.37 kB · 1 download Crash_2022_9_13_2-7-41.txt 94.25 kB · 1 download

As you can see, all of these crash logs have objects in common. Do you perhaps know how to fix this? Maybe remove the problematic  objects? Or somehow exclude it beofre generation? And if yes, then how do I do it?

I am using Veydogolt Trees, just mentioning if that's important, but if I disable DynDOLOD and go to the same places then I don't crash.

Post the log and debug log of DynDOLOD as explained in the first post.

Look up the mentioned  STAT base record xx058C0A in DynDOLOD.esp with xEdit and check which model.nif it actually uses. Then find that file in the load order and upload it.

[Eumeta]

2 hours ago, sheson said:

Form the log:

[00:27] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Better Dynamic Snow.esp NorTentLargeSnow [STAT:000EA068]>
[02:56] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Meshes\architecture\tents\largenordictent01.nif Skyrim.esm NorTentLarge [STAT:000800DE]>
[02:56] <Warning: File not found textures\clutter\common\ruground02_n.dds. Used by Skyrim.esm NorTentLarge [STAT:000800DE]>
[06:39] <Error: File not found textures\clutter\common\ruground02_n.dds>

It seems a mod is missing a texture or a requirement. Check which mod contains textures\clutter\common\ruground02.dds as that should also have textures\clutter\common\ruground02_n.dds

Hi, I checked my mods and found the 2 mods having riground02.dds do not contain its _n.dds equivalent, or any other mod. Version Alpha 95 successfully run wih the same errors where Dyndolod carried on. Do I forward you the log and debug file of that version?
 I installed Rugnarok to see if the problem goes away, and it did. Thank you.

[sheson]

1 hour ago, Eumeta said:

Hi, I checked my mods and found the 2 mods having riground02.dds do not contain its _n.dds equivalent, or any other mod. Version Alpha 95 successfully run wih the same errors where Dyndolod carried on. Do I forward you the log and debug file of that version?
 I installed Rugnarok to see if the problem goes away, and it did. Thank you.

What are the mods that are missing the texture?

If you found and installed the missing texture there is nothing else to do.

[Eumeta]

1 hour ago, sheson said:

What are the mods that are missing the texture?

If you found and installed the missing texture there is nothing else to do.

They are "Detailed Rugs" and "SSEUT - Clutter" to the latest version".

 

[sheson]

50 minutes ago, Eumeta said:

They are "Detailed Rugs" and "SSEUT - Clutter" to the latest version".

Could you check for me which which mod changes ..Meshes\Architecture\Tents\LargeNordicTent01.nif?

[Akidson]

4 hours ago, sheson said:

Post the log and debug log of DynDOLOD as explained in the first post.

Look up the mentioned  STAT base record xx058C0A in DynDOLOD.esp with xEdit and check which model.nif it actually uses. Then find that file in the load order and upload it.

Thank you for replying sheson. Here are all the files you've requested:

https://ufile.io/f/nyrh7

[sheson]

1 hour ago, Akidson said:

Thank you for replying sheson. Here are all the files you've requested:

https://ufile.io/f/nyrh7

See if this particular crash goes away / the crash log changes after replacing the NIF with the one attached. I would not be surprised if another form id/NIF has similar problems.

treepineforest03_F7CE5204passthru_lod.nif

[Akidson]

1 hour ago, sheson said:

See if this particular crash goes away / the crash log changes after replacing the NIF with the one attached. I would not be surprised if another form id/NIF has similar problems.

treepineforest03_F7CE5204passthru_lod.nif 11.47 kB · 0 downloads

Wow, thanks sheson, it worked! I'm no longer crashing in those areas. I will let you know if I enounter any more crashes like this one. If i do, is replacing the nif file  safe to do mid game? And also, if I may ask, what changes did you make to that file?

PS. DynDOLOD is amazing and you are a wonderful person for helping people with their issues

[sheson]

42 minutes ago, Akidson said:

Wow, thanks sheson, it worked! I'm no longer crashing in those areas. I will let you know if I enounter any more crashes like this one. If i do, is replacing the nif file  safe to do mid game? And also, if I may ask, what changes did you make to that file?

PS. DynDOLOD is amazing and you are a wonderful person for helping people with their issues

Replacing NIF files is safe.

There seem to be a lot of problematic 3D tree LOD models in the the two "3D Hybrid LODs" archives of the mod. The models contain NiSwitch nodes instead of being static 3D tree LOD models as explained in https://dyndolod.info/Help/3D-Tree-LOD-Model. They might work for object LOD generation as LODGen might be able to extract what it needs and remove duplicate stuff on the fly, but the way the NIFs are made they cause CTD when used directly in the game for dynamic LOD. They probably a (couple) dozen references here and there that could be problematic. They need to be fixed.

I made the 3D tree LOD a real static model by copying the actual crown BSTriShape to the root node and removed all the uneeded/interfering blocks. Comparing the NIFs in Nifskope should make it clear.

It might be possible to automate this if the split crown NIFs  are made available.