DynDOLOD 3.00 Alpha 190

[aazz]

Hello.
I don't think this is a problem with dyndolod, but rather my problem. However, I don't know how to find this problem, so I'm writing this post to see if you can help me.
Why does this blue ice appear here? When I get close, it turns white like the ice next to it.
I checked to see if the mesh path was wrong, but it's the same mesh as the white ice next to it. This only happens with lod, so what should I look into?

https://imgur.com/l7mSfLp

https://imgur.com/6MhaoW5

https://imgur.com/Zp9GWro

 

[sheson]

  On 3/23/2025 at 9:48 PM, aazz said:

Hello.
I don't think this is a problem with dyndolod, but rather my problem. However, I don't know how to find this problem, so I'm writing this post to see if you can help me.
Why does this blue ice appear here? When I get close, it turns white like the ice next to it.
I checked to see if the mesh path was wrong, but it's the same mesh as the white ice next to it. This only happens with lod, so what should I look into?

https://imgur.com/l7mSfLp

https://imgur.com/6MhaoW5

https://imgur.com/Zp9GWro

Expand  

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

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

https://dyndolod.info/Help/TexGen#Rendered-Object-LOD-Textures
Note that the list of rendered object LOD textures is not covering all vanilla rendered object LOD textures. It can update the rendered object LOD textures for the walled cities and most structures. However, far away mountains, icebergs and glaciers are not yet covered. If a mod makes changes to these relevant full textures, it should also include updated pre-rendered object LOD textures.

You are probably using a mod that changes the textures used by icebergs but it does not include updated LOD assets.

You may want to have a look at Glacier LOD Meshes.

[aazz]

  On 3/24/2025 at 8:04 AM, sheson said:

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

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

https://dyndolod.info/Help/TexGen#Rendered-Object-LOD-Textures
Note that the list of rendered object LOD textures is not covering all vanilla rendered object LOD textures. It can update the rendered object LOD textures for the walled cities and most structures. However, far away mountains, icebergs and glaciers are not yet covered. If a mod makes changes to these relevant full textures, it should also include updated pre-rendered object LOD textures.

You are probably using a mod that changes the textures used by icebergs but it does not include updated LOD assets.

You may want to have a look at Glacier LOD Meshes.

Expand  

DynDOLOD_SSE_Object_Report.7zFetching info...

https://imgur.com/a/9Mch4rs

What should I check here now??

I am already using Glacier LOD Meshes. I have also modified all the paths of the meshes.

[sheson]

  On 3/24/2025 at 4:21 PM, aazz said:

DynDOLOD_SSE_Object_Report.7z 451.97 kB · 1 download

https://imgur.com/a/9Mch4rs

What should I check here now??

I am already using Glacier LOD Meshes. I have also modified all the paths of the meshes.

Expand  

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.

[z929669]

I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif.

When I modify the original billboard included with DynDOLOD, save into a new NIF, and modify my DynDOLOD_SSE.ini likewise to use the new billboard model, I get an unexpected result. Clearly, the mipmaps generated by DynDOLOD for grass (in this case Cathedral Landscapes Complex Grass for ENB), use a method that differs from the mipmaps of the textures. From the result, it looks like some of the LOD grasses may be correct, but many are much too bright and wrong, so I cannot say for certain. The obviously wrong grasses are from 1024x2048 source cg textures saved with a2c threshold of 128, while those that look a bit more as expected correlate to 2048x4096 source textures saved at a a2c threshold of 106. I've been carefully testing the optimal thresholds of these grasses, and with respect to the grasses in the scene below, these are optimal for loaded grasses (not too thick or thin and no alpha color bias). Thus, I wanted to test using them for LOD.

using default NIF using modified NIF

logs

Note that the version of the mod I'm working with is in development, so if you want any particular files, I will post them.

---

PS: I'm not sure how mipmaps work for object LOD. I've seen that the TexGen billboards make it into the DynDOLOD_Tamriel.dds atlas, but the closest LOD grass seems brighter than the TexGen source billboard textures when usemipmaps keyword is used. How can I check the mip levels compared to my source?

PSS: I've checked the DynDOLOD_Tamriel.dds atlas mip levels now, and am seeing that higher mip levels are particularly opaque/bright for the problem grasses. Might the cause be that I am using the Kaiser algorithm for generating mipmaps? This works nicely for non-LOD textures, but it may be that opacity needs to be reduced at each mip level for LOD to avoid overly-bright grasses at lower mip levels. I'm not sure if the closest grass LOD uses mip 0 (from the TexGen billboards) on the atlas, because those aren't as bright as mipmaps at higher levels on the atlas. If the grasses on the atlas (and only the grasses) are now using my mipmaps, then Kaiser may be 'bad' for use with DynDOLOD.

PSSS: Well, it occurs to me that the TexGen billboard mipmaps shouldn't be getting used, since the usemipmaps keyword applies to generation subsequent to generating the billboards with TexGen, so I have no clue

[sheson]

  On 3/25/2025 at 7:20 PM, z929669 said:

I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif.

When I modify the original billboard included with DynDOLOD, save into a new NIF, and modify my DynDOLOD_SSE.ini likewise to use the new billboard model, I get an unexpected result. Clearly, the mipmaps generated by DynDOLOD for grass (in this case Cathedral Landscapes Complex Grass for ENB), use a method that differs from the mipmaps of the textures. From the result, it looks like some of the LOD grasses may be correct, but many are much too bright and wrong, so I cannot say for certain. The obviously wrong grasses are from 1024x2048 source cg textures saved with a2c threshold of 128, while those that look a bit more as expected correlate to 2048x4096 source textures saved at a a2c threshold of 106. I've been carefully testing the optimal thresholds of these grasses, and with respect to the grasses in the scene below, these are optimal for loaded grasses (not too thick or thin and no alpha color bias). Thus, I wanted to test using them for LOD.

using default NIF using modified NIF

logs

Note that the version of the mod I'm working with is in development, so if you want any particular files, I will post them.

---

PS: I'm not sure how mipmaps work for object LOD. I've seen that the TexGen billboards make it into the DynDOLOD_Tamriel.dds atlas, but the closest LOD grass seems brighter than the TexGen source billboard textures when usemipmaps keyword is used. How can I check the mip levels compared to my source?

PSS: I've checked the DynDOLOD_Tamriel.dds atlas mip levels now, and am seeing that higher mip levels are particularly opaque/bright for the problem grasses. Might the cause be that I am using the Kaiser algorithm for generating mipmaps? This works nicely for non-LOD textures, but it may be that opacity needs to be reduced at each mip level for LOD to avoid overly-bright grasses at lower mip levels. I'm not sure if the closest grass LOD uses mip 0 (from the TexGen billboards) on the atlas, because those aren't as bright as mipmaps at higher levels on the atlas. If the grasses on the atlas (and only the grasses) are now using my mipmaps, then Kaiser may be 'bad' for use with DynDOLOD.

PSSS: Well, it occurs to me that the TexGen billboard mipmaps shouldn't be getting used, since the usemipmaps keyword applies to generation subsequent to generating the billboards with TexGen, so I have no clue

Expand  

The point of TexGen and DynDOLOD is to not having to manually edit any of their outputs but instead use the existing settings and options to get the desired results or to report problems with the automatically generated output in order to have them troubleshooted and addressed.

https://en.wikipedia.org/wiki/Mipmap
In computer graphics, mipmaps ... are pre-calculated, optimized sequences of images, each of which is a progressively lower resolution representation of the previous.

Mipmaps are simply a list of images.

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

https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-190/page/539/#findComment-274396
https://stepmodifications.org/forum/topic/19077-optimizing-texture-alpha-threshold/https://dyndolod.info/Help/Texture-Resolution

https://dyndolod.info/Help/Texture-Resolution#Determine-Sensible-Texture-Resolutions has explanations how to see in the game if the largest mipmap is actually used.

[z929669]

  On 3/25/2025 at 8:58 PM, sheson said:

The point of TexGen and DynDOLOD is to not having to manually edit any of their outputs but instead use the existing settings and options to get the desired results or to report problems with the automatically generated output in order to have them troubleshooted and addressed.

Expand  

To be clear, I'm not modifying the outputs of the LOD patch. Rather, I am working with the source cg textures and generating LOD from those. Specifically, I'm optimizing the mipmaps of the Cathedral Landscapes Complex Grass for ENB grasses, because many of the finer grasses were too thin at distance:

From the documentation, DynDOLOD mipmaps are probably like this:

I will experiment using the cutout alpha, MipMapTests parameter in DynDOLOD, and solidifying specific TexGen grass billboards.

I'm still not clear on what UseMipMaps keyword is doing in this situation when applied to the grass billboard NIF. What explains the huge brightness difference? This would seem to have noting at all to do with TexGen, since the supposedly used mipmaps are in the source texture used by the full grass model as shown above.

 

[sheson]

  On 3/25/2025 at 9:42 PM, z929669 said:

To be clear, I'm not modifying the outputs of the LOD patch. Rather, I am working with the source cg textures and generating LOD from those. Specifically, I'm optimizing the mipmaps of the Cathedral Landscapes Complex Grass for ENB grasses, because many of the finer grasses were too thin at distance:

From the documentation, DynDOLOD mipmaps are probably like this:

I will experiment using the cutout alpha, MipMapTests parameter in DynDOLOD, and solidifying specific TexGen grass billboards.

I'm still not clear on what UseMipMaps keyword is doing in this situation when applied to the grass billboard NIF. What explains the huge brightness difference? This would seem to have noting at all to do with TexGen, since the supposedly used mipmaps are in the source texture used by the full grass model as shown above.

Expand  

I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif.

DynDOLO/object LOD does not use full grass textures. The billboard NIFs are used together with billboard textures.
Billboard textures generated by TexGen typically do not have mipmaps, since they are generated by DynDOLOD when textures are added to the object LOD atlas.

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

[z929669]

  On 3/25/2025 at 10:00 PM, sheson said:

I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif.

DynDOLO/object LOD does not use full grass textures. The billboard NIFs are used together with billboard textures.
Billboard textures generated by TexGen typically do not have mipmaps, since they are generated by DynDOLOD when textures are added to the object LOD atlas.

Expand  

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

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"?

[LiterallyACat]

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.

[sheson]

  On 3/25/2025 at 10:16 PM, z929669 said:

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

Expand  

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.

  On 3/25/2025 at 10:16 PM, 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"?

Expand  

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]

  On 3/25/2025 at 10:30 PM, 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.

Expand  

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]

  On 3/25/2025 at 10:00 PM, sheson said:

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

Expand  

  On 3/25/2025 at 10:37 PM, 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.

Expand  

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]

  On 3/25/2025 at 11:14 PM, 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?

Expand  

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.

  On 3/25/2025 at 11:14 PM, 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?

Expand  

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.