DynDOLOD 3.00 Alpha 198

[sheson]

9 minutes ago, LiterallyACat said:

So, I was having some issues with Windows freezing at random -- I don't know if it was due to an overclock or if something had simply gone wrong with an update or me fiddling with things incorrectly -- and so had to run TexGen and DynDOLOD repeatedly over the course of the day.

TexGen I was generating from scratch every time I ran DynDOLOD. In every run after that first one, TexGen and DynDOLOD's old outputs were deleted from MO2. I had also removed the Large References from the flat map plugins via xEdit using your page's small guide, so seeing the warnings reporting them afterwards was confusing (I loaded them into xEdit to check them, and the Large References were still gone) The logs I linked previously were the only time I did not run DynDOLOD from scratch, but here's some where I did run DynDOLOD from scratch. I think this is the second or third run I did from scratch; I didn't save the previous logs b/c the way that the warnings for the missing overridden records for DynDOLOD.esp were in them and I thought I must have forgotten to delete the old output or something -- it would be hard for a plugin that DynDOLOD had just created to already have that issue.

I ran TexGen and DynDOLOD from scratch again the next day after leaving my computer off overnight, and the logs from that run were as I was expecting for running from scratch. I guess I don't really know if it's possible, but I think Windows might not have correctly been flagging the files as deleted, or MO2 was accepting commands to delete them and showing them as gone incorrectly? Or I'm (having worse) issues with memory and perceiving reality.

I also ended up reinstalling windows, and the issues with random freezing seem to have stopped (it was happening frequently and hasn't recurred over the past day and a half).

I apologize for the long-winded post filled with probably unneeded details; I wanted to respond and make sure I explained things instead of saying, "It seems fixed now! Either I was having a massive filesystem/operating system problem, or I have a major case of PEBCAK." I do not want to waste your time, but I also don't know if it may be important to respond fully and truthfully.

No worries. Whenever I run into an issue where I change something and it does not seem to make any or the expected  difference, it is because the file I am updating is not the one being used by whatever I use to check the change. For me that typically happens when I make backups in different directories or drives. Also MO2s virtual file system could probably get confused if you unlock MO2 while tools are being started with it. I have that turned off, because is always several tools open at the same, some with different load orders, different games even. The important part is that you addressed and fixed the issues.

[z929669]

On 3/26/2025 at 8:14 AM, sheson said:

What matters are the generated billboard textures and text file for the grass record. Verify those are as expected.

If LODGen applies the ComplexGrassBrightness* values depends on the line Complex=True in the billboard txt. That should not randomly change.

Check if the billboard text file contains that line.

LODGen multiplies the vertex colors of the billboard NIF with these values when they are added to the object LOD meshes.

No sure if reloading cells refers to loading in the game. That will not change the vertex colors in the LOD meshes.
Nothing is rendered from the grass cache. The cache files are used for position, rotation, scale, brightness (single value applied to all 3 vertex color channels equally).

Is it possible that setting a nonzero Smoothness value could result in Complex=true not being written to the billboard txt? Perhaps the normal is changed such that it's not being considered as such by TexGen? As I await your response, here's some background...

In an effort to find the best TexGen and DynDOLOD settings for my CG, I have regenerated TexGen and DynDOLOD from scratch about 7 times since I last reported my 'blue' CG issue being a fluke, and I similarly have had proper results (no blue grasses = all being tagged complex). As I mentioned previously, that seemed to have randomly resolved. However, it seems possible that when I alter Smoothness to be nonzero, TexGen fails to register the billboards of a few grass texture sets as complex. In hindsight, his is what I must've done the first time I reported this issue. That time, I tested with Smoothness=50. Just today, I set Smoothness=70, and was able to repeat the improper result.

Because I'm as yet uncertain this one change is reproducible (or even causal), I will regenerate again with Smoothness=0 (default) to verify proper results once again. Then I will repeat with Smoothness=50. If the results are improper, I think this would be sufficient evidence that Smoothing the normal might interfere with CG data processing.

I will reply to this post once I have the results.

TexGen logs

---

UPDATE: I reran TexGen to process HD grass billboards only 6 times with Smoothness=0. I always got 70 billboard txt files. Each run, not all files received Complex=true line:

• t1: 64/70
• t2: 58/70
• t3: 57/70
• t4: 54/70
• t5: 57/70

Obviously, some grasses don't get flagged consistently between runs. The likelihood of certain grasses to be ambiguously flagged is greater than others (there are specific grasses that are prone to not getting flagged, but sometimes are still flagged).

I repeated a final time with Smoothness=70 and got 56/70. So Smoothness has nothing to do with it, IMO. Rather, there's something about the flagging method that results in the inconsistency, or there's something about the TexGen process and/or my environment that bugs out the process. Additionally, there's something about certain textures that make them prone to improper treatment. Each of the grass textures were constructed in an identical process, and each has 32x32 pixels in the lower left with r127, g127, b255.

fortunately, it'seasy to quickly assess what txt files contain 'complex' string using Explorer, which searches within txt files in addition to file names (presumably, only if indexing is turned on). I verified that Explorer does this correctly by manually confirming that 12/70 text files lacked 'complex=true' line in t2 run.

This issue might be common and would normally go unnoticed, because most people running CG use the standard GrassBrightness* values, which masks the problem for the most part. I just happen to be testing with a strong blue hue to verify that CG grasses are all being treated as such.

[sheson]

9 hours ago, z929669 said:

I reran TexGen to process HD grass billboards only 6 times with Smoothness=0. I always got 70 billboard txt files. Each run, not all files received Complex=true line:

• t1: 64/70
• t2: 58/70
• t3: 57/70
• t4: 54/70
• t5: 57/70

Obviously, some grasses don't get flagged consistently between runs. The likelihood of certain grasses to be ambiguously flagged is greater than others (there are specific grasses that are prone to not getting flagged, but sometimes are still flagged).

I repeated a final time with Smoothness=70 and got 56/70. So Smoothness has nothing to do with it, IMO. Rather, there's something about the flagging method that results in the inconsistency, or there's something about the TexGen process and/or my environment that bugs out the process. Additionally, there's something about certain textures that make them prone to improper treatment. Each of the grass textures were constructed in an identical process, and each has 32x32 pixels in the lower left with r127, g127, b255.

fortunately, it'seasy to quickly assess what txt files contain 'complex' string using Explorer, which searches within txt files in addition to file names (presumably, only if indexing is turned on). I verified that Explorer does this correctly by manually confirming that 12/70 text files lacked 'complex=true' line in t2 run.

This issue might be common and would normally go unnoticed, because most people running CG use the standard GrassBrightness* values, which masks the problem for the most part. I just happen to be testing with a strong blue hue to verify that CG grasses are all being treated as such.

The provided debug log file is only from a single run.

As explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs, the normal logs appends, while the debug log gets replaced every time. So when having different results between two runs, make sure to keep and upload the 2 different debug logs. An easy method to keep all log files is to rename the log folder after every run.

If you already know which billboard text files are different between two runs, then report their filename(s).
If grasses from mods are involved, then report the names of the mods and provide links if possible.

Check if there is anything different with this test  version https://mega.nz/file/odIHRbga#6pcjpm9KOi3Lv0i9DsXLILJz5qTNHEM5WfeMMIWkWlA

[z929669]

5 hours ago, sheson said:

The provided debug log file is only from a single run.

As explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs, the normal logs appends, while the debug log gets replaced every time. So when having different results between two runs, make sure to keep and upload the 2 different debug logs. An easy method to keep all log files is to rename the log folder after every run.

If you already know which billboard text files are different between two runs, then report their filename(s).
If grasses from mods are involved, then report the names of the mods and provide links if possible.

Check if there is anything different with this test  version https://mega.nz/file/odIHRbga#6pcjpm9KOi3Lv0i9DsXLILJz5qTNHEM5WfeMMIWkWlA

Noted.

I will check this test version later today. In the meantime, here's a link to my last TexGen debug log, where 63/73 files were properly flagged. I'm not sure why there were 73 txt files this one time. I've also included the texture assets. Some of the recurring, ambiguously-flagged grasses are:

• fieldgrassTU (11)
• fieldgrassTU (9)
• fieldgrassTU (1)
• ffgrass01
• flowergrasssaxifrage

There are several others though.

The load order hasn't changed in days. Only the TexGen settings were changed in the mentioned TexGen runs.

[z929669]

14 hours ago, sheson said:

The provided debug log file is only from a single run.

As explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs, the normal logs appends, while the debug log gets replaced every time. So when having different results between two runs, make sure to keep and upload the 2 different debug logs. An easy method to keep all log files is to rename the log folder after every run.

If you already know which billboard text files are different between two runs, then report their filename(s).
If grasses from mods are involved, then report the names of the mods and provide links if possible.

Check if there is anything different with this test  version https://mega.nz/file/odIHRbga#6pcjpm9KOi3Lv0i9DsXLILJz5qTNHEM5WfeMMIWkWlA

 

8 hours ago, z929669 said:

Noted.

I will check this test version later today. In the meantime, here's a link to my last TexGen debug log, where 63/73 files were properly flagged. I'm not sure why there were 73 txt files this one time. I've also included the texture assets. Some of the recurring, ambiguously-flagged grasses are:

• fieldgrassTU (11)
• fieldgrassTU (9)
• fieldgrassTU (1)
• ffgrass01
• flowergrasssaxifrage

There are several others though.

The load order hasn't changed in days. Only the TexGen settings were changed in the mentioned TexGen runs.

The test version resolved the issue.

I generated only HD grass with TexGen using the Alpha 190 version twice to confirm the issue and included the logs and the txt files with the missing line from each run.

I repeated with the test version, and all billboard txt files contained the Complex=True line.

cg-tests

[sheson]

8 hours ago, z929669 said:

The test version resolved the issue.

I generated only HD grass with TexGen using the Alpha 190 version twice to confirm the issue and included the logs and the txt files with the missing line from each run.

I repeated with the test version, and all billboard txt files contained the Complex=True line.

cg-tests

That is great. Thanks for testing.

[aazz]

On 3/29/2025 at 1:41 AM, MisterMorden said:

Depending on what mod you're using for icebergs, glaciers, etc the full model may or may not use the exact texture that the dyndolod resources lod model uses.  Also, even if it uses the same texture, the lod model can't use the same mesh flags that the full model can so it won't look the same.  As a way to smooth visual transitions for this, I personally use the Glacier LOD Meshes mod and then (because it doesn't include the "_anim" lod models that dyndolod resources provides for Animated Icebergs' full models) I copy and rename the corresponding lod model to overwrite the ones in dyndolod resources.  Glacier LOD Meshes uses edited lod models that retain the look of the utilized texture more accurately.

PS - GLM is an oldrim mod but since it is just meshes it will work as is.

 

On 3/29/2025 at 2:32 AM, sheson said:

You seem to be using Animated Icebergs, which replaces the meshes from iceberglarge.nif to iceberglarge_anim.nif, which means the LOD models from Glacier LOD Meshes are not used but the ones based on the vanilla LOD models included in DynDOLOD Resources, which depend on a vanilla rendered object LOD texture iceberglargelod.dds that can currently not be automatically updated.

This might work:
Find meshes\lod\ice\iceberglarge_lod_[0|1|2].nif in Glacier LOD Meshes and copy them to iceberglarge_anim_lod_[0|1|2].nif
icebergsmall01_lod.nif to icebergsmall01_anim_lod_1.nif
icebergsmall02_lod.nif to icebergsmall02_anim_lod_1.nif

Then "Execute LODGen" for Tamriel in expert mode to generate updated object LOD meshes. See https://dyndolod.info/Help/Expert-Mode

I am not 100% sure that it will work, since I didn't have time to test for myself, so report results.

I'm a little late in confirming this. I tried both and they didn't work.

https://imgur.com/a/T9IcCpf

Is there anything else I can try?

[MisterMorden]

32 minutes ago, aazz said:

 

I'm a little late in confirming this. I tried both and they didn't work.

https://imgur.com/a/T9IcCpf

Is there anything else I can try?

All I can suggest to check is that the renamed meshes are spelled correctly (check the data tab in MO2 to make sure they overwrite dyndolod resources) and also look at the winning nif in nifskope to make sure it looks just like the one it's copied from in Glacier LOD Meshes.  I also use a mesh rule for icebergs and glaciers setting level0 for all LOD levels (except 32 depending on your map situation).  Make sure there are no other mesh rules above the one you create or it will override it.

[aazz]

4 hours ago, MisterMorden said:

All I can suggest to check is that the renamed meshes are spelled correctly (check the data tab in MO2 to make sure they overwrite dyndolod resources) and also look at the winning nif in nifskope to make sure it looks just like the one it's copied from in Glacier LOD Meshes.  I also use a mesh rule for icebergs and glaciers setting level0 for all LOD levels (except 32 depending on your map situation).  Make sure there are no other mesh rules above the one you create or it will override it.

https://imgur.com/u2L9mfR

After a few attempts I succeeded.
My solution was to copy all the LOD meshes in IMR and Glacier LOD and paste "anim_lod_[0|1|2]".
Thanks a lot for your help.

[sheson]

14 hours ago, aazz said:

I'm a little late in confirming this. I tried both and they didn't work.

https://imgur.com/a/T9IcCpf

Is there anything else I can try?

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.
Also upload Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make a useful screenshot of the full model with more informative console.

8 hours ago, aazz said:

https://imgur.com/u2L9mfR

After a few attempts I succeeded.
My solution was to copy all the LOD meshes in IMR and Glacier LOD and paste "anim_lod_[0|1|2]".
Thanks a lot for your help.

[0|1|2] is a placeholder for 3 variation of the actual filenames.

Find meshes\lod\ice\iceberglarge_lod_[0|1|2].nif in Glacier LOD Meshes and copy them to iceberglarge_anim_lod_[0|1|2].nif is a shorthand for 
iceberglarge_lod_0.nif to iceberglarge_anim_lod_0.nif
iceberglarge_lod_1.nif to iceberglarge_anim_lod_1.nif
iceberglarge_lod_2.nif to iceberglarge_anim_lod_2.nif

[BrotherShamus]

I'm hoping to clarify something before I begin generating LOD.  I'm using this mod https://www.nexusmods.com/skyrimspecialedition/mods/46372?tab=files (v1.2 in the 'old files section) to replace the Shrine of Azura.  I'm using the option in the FOMOD to make the statue three times its original size.  I'm also using this mod https://www.nexusmods.com/skyrimspecialedition/mods/46522?tab=files to provide ENB lights on the sun and moon.  Utilizing this guide https://dyndolod.info/Mods/Replaced-Full-Model-Example-Azura-Statue it seems I should be using the 2nd mesh mask rule (for the ENB lights) but for the larger statue, it seems I should be using the first mesh mask rule.  If I change nothing when generating LOD, the statue appears perfectly but the ENB lights do not.  I may have misunderstood something but in a previous post, it appears that it's suggested to use the full model but they weren't using ENB lights.  Any help is greatly appreciated.

I've set the correct ENB settings as well... just wanted to mention that.

Edited April 4, 2025 by BrotherShamus

[mostwanted11]

What causes texgen to skip over some grasses when creating billboards? The result is that these grasses typically don't receive any lods. This issue only happens with this mod https://www.nexusmods.com/skyrimspecialedition/mods/139896. I have recalc'd bounds and i made a txt file in my mods folder and set the specific mesh to true, but the file that gets generated in texgen turns them to false like this "groundcover.esp;0000030A;r_curly_grass01,True,False"

Edited April 4, 2025 by mostwanted11

[sheson]

12 hours ago, BrotherShamus said:

I'm hoping to clarify something before I begin generating LOD. I'm using this mod https://www.nexusmods.com/skyrimspecialedition/mods/46372?tab=files (v1.2 in the 'old files section) to replace the Shrine of Azura. I'm using the option in the FOMOD to make the statue three times its original size. I'm also using this mod https://www.nexusmods.com/skyrimspecialedition/mods/46522?tab=files to provide ENB lights on the sun and moon. Utilizing this guide https://dyndolod.info/Mods/Replaced-Full-Model-Example-Azura-Statue it seems I should be using the 2nd mesh mask rule (for the ENB lights) but for the larger statue, it seems I should be using the first mesh mask rule. If I change nothing when generating LOD, the statue appears perfectly but the ENB lights do not. I may have misunderstood something but in a previous post, it appears that it's suggested to use the full model but they weren't using ENB lights. Any help is greatly appreciated.

I've set the correct ENB settings as well... just wanted to mention that.

No rule is required if a mod only changes the translation (position, rotation or scale) of a reference.
Use the second rule for the ENB lights.,

[sheson]

12 hours ago, mostwanted11 said:

What causes texgen to skip over some grasses when creating billboards? The result is that these grasses typically don't receive any lods. This issue only happens with this mod https://www.nexusmods.com/skyrimspecialedition/mods/139896. I have recalc'd bounds and i made a txt file in my mods folder and set the specific mesh to true, but the file that gets generated in texgen turns them to false like this "groundcover.esp;0000030A;r_curly_grass01,True,False"

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. Also upload the file you created.

Provide a link to the used grass mod(s).

[mostwanted11]

40 minutes ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. Also upload the file you created.

Provide a link to the used grass mod(s).

https://ufile.io/kxe8o99l

https://www.nexusmods.com/skyrimspecialedition/mods/139896

 

if i crop the complex textures, they dont get skipped anymore

 

and the file i made i put in the logs, but i put it in mo2 in data/dyndolod/

Edited April 5, 2025 by mostwanted11