DynDOLOD 3.00 Alpha 190

[sheson]

  On 3/26/2025 at 3:20 AM, z929669 said:

Since I've not gotten further clarification/confirmation on my last post, I'm moving on to another issue.

In my continued testing, I've noticed a cg grass that is not treated as such by DynDOLOD. It's being treated as a basic grass. The coloring is controlled by GrassBrightness* rather than ComplexGrassBrightness* in DynDOLOD_SSE.ini. This can be seen in my most recent run where I've set GrassBrightness* to be pure blue.

cg grass colored by GrassBrightness*

After looking more closely, I believe the grass to be fieldgrassTU (1).nif (fieldgrasstu (1).dds), which is a cg texture included with Cathedral Landscapes Complex Grass for ENB. It seems that the TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process. I can't find anything suspicious with this model in the DynDOLOD debug log. I'd like to understand the cause, because this issue isn't consistent between DynDOLOD runs. In my previous run, this blue was very dense and impacted larger areas. I didn't get a screenshot then because I was testing with MipMapTests and didn't want to conflate the two results (that's another matter).

Anyway, it explains why my LOD results are inconsistent in terms of matching full with LOD grasses if some grasses are being treated as basic as opposed to complex by DynDOLOD. I think grass placements can vary at generation and/or cell load time, so that may explain why I have less blue this run and this same save.

suspect grass

logs

Expand  

No clue what TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process is supposed to mean.

The detection if a grass full texture is complex depends on the full texture. The TexGen debug log shows that the texture is being split into 2 temp textures, which should mean it was detected as complex.

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

https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
To get closer to LOD, toggle to the free fly camera with tfc in console.

[z929669]

  On 3/26/2025 at 6:39 AM, sheson said:

The shape names in the billboards NIF that are for DynDOLOD like usemipmaps or noatlas should have no effect since the billboards NIFs are not processed to find textures to be added to the object LOD atlas. In addition, billboards have no mipmaps that could be used.

I would assume there is also something else different between the two generation, either in the billboard NIF and/or billboard textures. I can not really answer this question without the different assets being used.

Expand  

Thanks for confirming why usemipmaps won't work on the NIF when the texture path of the NIF points to a texture that has no mipmaps. This makes sense now and confirms that my understanding of how it works is not totally off. I'm baffled as to shy there was a brightness change on that run though, as none of the textures changed. It may be related to the other issue with the blue GrassBrightness* values, which were set to be very bright that run.

  On 3/26/2025 at 7:01 AM, sheson said:

No clue what TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process is supposed to mean.

Expand  

The TexGen debug I posted has over ten thousand lines processing the NIF I posted (and a few others before that):

[01:32] [SplitComplexGrassTexture] <Debug: Processing textures\landscape\grass\fieldgrassTU (1).dds>
[01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] ResourceExists>
[01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] DXGI_FORMAT_BC7_UNORM>
[01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] Executing "C:\Modding\Tools\DynDOLOD\Edit Scripts\Texconvx64.exe" -nologo -gpu 0 -y -m 1 -aw 256 -f R8G8B8A8_UNORM -srgb -o "C:\Users\David\AppData\Local\Temp\TexGen_SSE" "C:\Users\David\AppData\Local\Temp\TexGen_SSE\5B1472EAA4EC4240B73F173B983A1608.dds">
[01:32] [SplitComplexGrassTexture] <Debug: Splitting complex grass textures textures\landscape\grass\fieldgrassTU (1).dds into C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 1, 0 0, 0 0>
[01:32] [SplitComplexGrassTexture] <Debug: Splitting complex grass textures textures\landscape\grass\fieldgrassTU (1).dds into C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds>
[01:32] [dynSaveImage] <Debug: Saving C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds>
[01:32] [dynSaveImage] <Debug: Saving C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds>
[01:32] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1>
[01:32] [TwbRender.LoadTexture] <Debug: Used Texture 2 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1>
[01:32] [TwbRender.LoadTexture] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]>
[01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0>
[01:32] [LoadGLMultiImage] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds>
[01:32] [TwbRender.ReserveID] <Debug: Creating 7 LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds>
[01:32] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds mipmap max 10>
[01:32] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds done 10>
[01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:32] [TwbRender.LoadTexture] <Debug: Used Texture 2 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1>
[01:32] [TwbRender.LoadTexture] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]>
[01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0>
[01:32] [LoadGLMultiImage] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds>
[01:32] [TwbRender.ReserveID] <Debug: Creating 8 LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds>
[01:33] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds mipmap max 10>
[01:33] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds done 10>
[01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 2 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1>
[01:33] [TwbRender.LoadTexture] <Debug: Loading textures\landscape\grass\fieldgrassTU (1).dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]>
[01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0>
[01:33] [LoadGLMultiImage] <Debug: Loading textures\landscape\grass\fieldgrassTU (1).dds>
[01:33] [TwbRender.ReserveID] <Debug: Creating 9 LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds>
[01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Loading Meshes\landscape\grass\fieldgrasstu (1).nif>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.LoadScene C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 30001 (Meshes) aDC: 0>
[01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Vertexdata: 9>
[01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif 0 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 7>
[01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 8>
[01:33] [TwbRender.LoadScene] <Debug: Checked 1 FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.LoadScene C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 20002 (Render #0) aDC: 0>
[01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0>
[01:33] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: FFFFFFFFEF0117F4 aRC: 20002 (Render #0) aDC: 0>
[01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: FFFFFFFFEF0117F4>
[01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0>
[01:33] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640>
[01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 20002 (Render #0) aDC: 0>
[01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1>
[01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E>
[01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0>
[01:34] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1>

...these last 20-ish lines repeat similarly for hundreds more iterations and thousands more lines for this one model. No other but a handfull of textures consume this volume of log space just before it.

 

  On 3/26/2025 at 7:01 AM, sheson said:

The detection if a grass full texture is complex depends on the full texture. The TexGen debug log shows that the texture is being split into 2 temp textures, which should mean it was detected as complex.

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

https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
To get closer to LOD, toggle to the free fly camera with tfc in console.

Expand  

The full texture of all these tundra grasses are constructed in the same 1x2 format as the texture I posted with the model previously. The TexGen preview of every single grass in my game registeres as cg. Therefore, if I have these patches of blue grass, some of them are being treated as basic grass by DynDOLOD for some reason. I'm pretty sure it's fieldgrasstu (1), but it's not easy to distinguish from the low-res LOD model using tfc. Since I cannot use MIC, there's some guesswork involved.

I'm hoping you will trust the facts though and that some cg grasses are not being treated as complex. I've reloaded this save on this generation several times, and the same grasses appear as blue. As I mentioned, in a previous generation, the volume of blue tundra grasses was much higher. Later today, I will exit and reload these cells to see if the pattern and frequency changes. It may have something to do with rendering from the grass cache, IDK, but it's a 'thing'.

[sheson]

  On 3/26/2025 at 11:58 AM, z929669 said:

The TexGen debug I posted has over ten thousand lines processing the NIF I posted (and a few others before that):

...these last 20-ish lines repeat similarly for hundreds more iterations and thousands more lines for this one model. No other but a handfull of textures consume this volume of log space just before it.

Expand  

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

  On 3/26/2025 at 11:58 AM, z929669 said:

The full texture of all these tundra grasses are constructed in the same 1x2 format as the texture I posted with the model previously. The TexGen preview of every single grass in my game registeres as cg. Therefore, if I have these patches of blue grass, some of them are being treated as basic grass by DynDOLOD for some reason. I'm pretty sure it's fieldgrasstu (1), but it's not easy to distinguish from the low-res LOD model using tfc. Since I cannot use MIC, there's some guesswork involved.

Expand  

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.

  On 3/26/2025 at 11:58 AM, z929669 said:

I've reloaded this save on this generation several times, and the same grasses appear as blue. As I mentioned, in a previous generation, the volume of blue tundra grasses was much higher. Later today, I will exit and reload these cells to see if the pattern and frequency changes. It may have something to do with rendering from the grass cache, IDK, but it's a 'thing'.

Expand  

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

[z929669]

  On 3/26/2025 at 1:14 PM, 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).

Expand  

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/24/2025 at 5:52 PM, 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.

Expand  

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 Thursday at 01:38 AM by aazz

[MisterMorden]

  On 3/27/2025 at 1: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

Expand  

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 Friday at 04:43 PM by MisterMorden

[sheson]

  On 3/27/2025 at 1: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

Expand  

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]

  On 3/28/2025 at 4:41 PM, 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.

Expand  

 

  On 3/28/2025 at 5:32 PM, 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.

Expand  

Wouldn'tsomething like this also work?

[sheson]

  On 3/28/2025 at 11:50 PM, z929669 said:

Wouldn'tsomething like this also work?

Expand  

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 10: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.

Expand  

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]

  On 3/29/2025 at 5:21 PM, 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.

Expand  

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 1:14 PM, 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).

Expand  

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]

  On 3/30/2025 at 3:26 AM, 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.

Expand  

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]

  On 3/30/2025 at 7:50 AM, 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

Expand  

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]

  On 3/30/2025 at 7:50 AM, 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

Expand  

 

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

Expand  

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