DynDOLOD 3.00 Alpha 196

[z929669]

10 hours ago, 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).

Good points, thanks. The billboards exist for fieldgrass (1) in two forms: fieldgrasstu (1)_00000db2 & fieldgrasstu (1)_000008a0 (I'm not sure what the numeric portions refer to. They are not FormIDs). 00000db2 has complex=true, but 000008a0 is missing this line, so that must be the issue.

There are 54 cg grass files in the mod, and I have 70 TXT billboard files. Each grass has between 1 and 3 billboard variants (no clue why this varies), and a small handfull are missing the cg line in the TXT file for some reason.

Is there something I can check or test to dig a bit deeper? As I mentioned, each was produced using the same methodology, so I am confident that the source textures aren't the cause of this inconsistency.

---

I've run TexGen again, and the issue did not recur. That previous TexGen session did not complete successfully it seems ...even though I was prompted to exit TexGen normally.

Running DynDOLOD against the new TexGen output produced the expected result, so this latest issue was a non-repeatable fluke. Nothing at all has changed in the LO or process, so let's chalk it up to random issues with the OS. Thanks for your time.

 

[aazz]

On 3/25/2025 at 2:52 AM, sheson said:

The requested DynDOLOD log and debug log were not provided. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

None of the screenshots seem to show the full model with more informative console information. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots. 

The used full model filename or base record form ID of the full model can be used to look up in the object report which LOD assets are actually being used.

make sure the LOD assets shipping with the mod overwrite DynDOLOD Resources.

I tried running dyndolod again a few times

log

The objects circled in red in the first screenshot are the same objects. I don't know why only some of them turn blue.

https://imgur.com/TPNd2xa

When you get close, it starts flashing blue and white like this and then turns completely white.

Here's a close-up shot of the console. All my mod lod files are overwriting dyndolod resources

Edited March 27 by aazz

[MisterMorden]

On 3/26/2025 at 8:34 PM, aazz said:

I tried running dyndolod again a few times

log

The objects circled in red in the first screenshot are the same objects. I don't know why only some of them turn blue.

https://imgur.com/TPNd2xa

When you get close, it starts flashing blue and white like this and then turns completely white.

Here's a close-up shot of the console. All my mod lod files are overwriting dyndolod resources

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.

Edited March 28 by MisterMorden

[sheson]

On 3/27/2025 at 2:34 AM, aazz said:

I tried running dyndolod again a few times

log

The objects circled in red in the first screenshot are the same objects. I don't know why only some of them turn blue.

https://imgur.com/TPNd2xa

When you get close, it starts flashing blue and white like this and then turns completely white.

Here's a close-up shot of the console. All my mod lod files are overwriting dyndolod resources

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.

[z929669]

7 hours ago, 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.

 

6 hours ago, 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.

Wouldn'tsomething like this also work?

[sheson]

11 hours ago, z929669 said:

Wouldn'tsomething like this also work?

Not entirely sure what "this" means. The Glaciers LOD mod includes that rule for TexGen already and has updated LOD models for the vanilla icebergs that use the generated stitched object texture LOD texture instead. It does not have updated LOD models for the Animated Icebergs mod.

[LiterallyACat]

On 3/25/2025 at 5:53 PM, sheson said:

The normal DynDOLOD log does not contain the initial output generation from scratch.

The initial generation from scratch or maybe a later update generation should have generated the nohavok meshes to the output folder. The nohavok meshes are copies of full models with flags unset in the BSX block.
Either the reported textures were always missing or the textures were deleted at some point as well.

The "is missing an overriden record" is a message from the xEdit code. I believe it means group record is orphaned with references in the plugin.|
Was the plugin loaded/edited in CK or other tools than xEdit?

You should generate new output for the current load order from scratch as the message "Update existing plugin(s)? If this is not successful start from scratch" suggests.

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.

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