DynDOLOD 3.00 Alpha 198

[sheson]

41 minutes ago, z929669 said:

Okay, so is it accurate to say that DynDOLOD generates mipmaps using the TexGen billboard texture as a basis at mip 0?

By default a billboard texture has no mipmaps, so there is only one resolution to use.

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are.

41 minutes ago, z929669 said:

If that's the case, I still don't understand the following. It implies that the mipmaps defined in the full texture are used rather than them being generated by DynDOLOD (because TexGen billboard textures do not have mipmaps, as you said):

https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names - usemipmaps - if the textures used by this shape are added to the texture atlas, use original mipmaps instead of generating them. See above.

where above exactly?

What is the "original mipmaps"?

I linked and quoted the "above" from the same page already:

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 be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames.

The page explains 3D tree LOD model creation and the use of full textures for the branches.
The original mipmaps of the texture defined by the NIF, e.g. the 3D tree LOD model.

In case of a billboard NIF, the defined textures are replaced by the actual billboard textures, so their mipmaps if they have any.

[sheson]

9 minutes ago, LiterallyACat said:

I have been informed of a lack of these two LOD meshes, as well as 3 textures:

Warning: File not found Meshes\dyndolod\nohavok\fireplacewood01burning_nohavok.nif. Used by DynDOLOD.esm FireplaceWood01Burning_DynDOLOD_BASERECORD [MSTT:53002106]
Warning: File not found Meshes\dyndolod\nohavok\siltstrider01_nohavok.nif. Used by DynDOLOD.esm SiltStrider_DynDOLOD_BASERECORD [MSTT:5300243A]

...

Warning: File not found textures\clutter\woodfire003.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19]
Warning: File not found textures\clutter\woodfire004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19]
Warning: File not found textures\clutter\woodfirecap004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19]

My quick search for 'fireplace', 'woodfire00', and 'siltstrider' did not seem to yield any results in these forums, and my check of the MO2 VFS also verified that they don't exist in an incorrect location.  Is this an issue that needs to be rectified?

Link to the full logs, if desired.

DynDOLOD_SSE_log.txt

DynDOLOD_SSE_Debug_log.txt

Additionally (in the same logs), I noticed these:

[00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F]
[00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F]
[00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F]
[00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F]
[00:07] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F]

I haven't seen these errors before and can't find any info on them.

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.

[z929669]

1 hour ago, sheson said:

TexGen by default ignores mipmaps of complex grass full textures when rendering billboards.
UseMipmapsComplexGrass setting in TexGen_SSE.INI

28 minutes ago, sheson said:

The page explains 3D tree LOD model generation and the use of full textures for the branches.
The original mipmaps of the texture defined by the NIF, e.g. the 3D tree LOD model.

Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees?

I'm still confused by the very bright LOD grass result I posted at the start of this conversation when using this keyword in the model and assigning it to ComplexGrassBillboard. Was that just me breaking something that might cause that outcome?

[z929669]

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

[sheson]

6 hours ago, z929669 said:

Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees?

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.

7 hours ago, z929669 said:

Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees?

I'm still confused by the very bright LOD grass result I posted at the start of this conversation when using this keyword in the model and assigning it to ComplexGrassBillboard. Was that just me breaking something that might cause that outcome?

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.

[sheson]

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

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]

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

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.

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

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.

 

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

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]

1 hour ago, 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.

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

1 hour ago, 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.

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.

1 hour ago, 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'.

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]

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, 2025 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, 2025 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.