DynDOLOD 3.00 Alpha 190

[sheson]

  On 3/28/2023 at 11:03 PM, geoffreyvanvugt said:

Hi Sheson.

Am i correct and did you add lod meshes for Natural Waterfalls in latest Resources 122? And if so, does the lod meshes from the mod itself is still required?

Thnx and best regards.

Expand  

https://dyndolod.info/Mods/Waterfalls
DynDOLOD Resources SE contains specifically made dynamic LOD and static LOD models for waterfalls.
For best visuals and performance typically do not install any 3rd party LOD resources - remove them if necessary.
* Natural Waterfalls

The mod does not really contain "LOD" meshes. It contains renamed full models. This is not how any of this is supposed to be done.

If there are log messages like https://dyndolod.info/Messages/LOD-Model-Has-Same-CRC32-As-Full-Model, for any assets from a listed mod, then its best to remove them.

[heheloveer]

Tested with version 122 and the large reference bugs workaround seemed to be applying when loading saves in Tamriel worldspace, since I haven't noticed any large reference bugs happening. However, full grass and grass lods can still overlap outside Whiterun with NGIO/DynDOLOD grass mode 2 and after a closer look I don't think this problem's related to the typical large reference bugs. Here's what I noticed:

1) Applying LOD Unloading Bug Fix could fix the large reference bugs in my experience (I imagine the large reference bugs workaround actively applying during the process) but it changed nothing in this case.

2) After using the tll command, I noticed there weren't many full object models outside the loaded area and upon clicking them in the console, I think these full models were all things added by the Whiterun Exterior patch, not large references. The only "large reference" I could see was the full grass.

A video to illustrate my findings: https://anonfiles.com/U0fcE3h2zb/Skyrim_Special_Edition_2023_03_29_19_10_01_mp4

Judging from this, I think there wouldn't be any overlapping if I used grass mode 1, but this is still strange. I think you once said the large reference system works in child worldspaces just like they do in parent worldspaces? Is there any other related setting or something that I'm unaware of?

Log and debug log, in case you need them: https://anonfiles.com/F6g4E1h4zf/Logs_0329_rar

  On 3/29/2023 at 7:47 AM, sheson said:

https://dyndolod.info/Mods/Waterfalls
DynDOLOD Resources SE contains specifically made dynamic LOD and static LOD models for waterfalls.
For best visuals and performance typically do not install any 3rd party LOD resources - remove them if necessary.
* Natural Waterfalls

The mod does not really contain "LOD" meshes. It contains renamed full models. This is not how any of this is supposed to be done.

If there are log messages like https://dyndolod.info/Messages/LOD-Model-Has-Same-CRC32-As-Full-Model, for any assets from a listed mod, then its best to remove them.

Expand  

So you are saying we should remove every lod related mesh/texture in WENB and Natural Waterfalls, or just remove those meshes mentioned in the LOD Model * Has Same CRC32 As Full Model messages?

[ToosTruus]

Ok. Right.

First, thank you for providing the correct Lod meshes. 

Thank you for quick answer. I did not know this. Learning everyday. I checked Bright Water Fix for RWT and that mod has same "lods" build for  RWT.

Checked file size with the ones from RWT and they are exactly the same. I guess they are the full models too renaming with _dyndolod_lod?

 

 

[sheson]

  On 3/29/2023 at 11:34 AM, heheloveer said:

So you are saying we should remove every lod related mesh/texture in WENB and Natural Waterfalls, or just remove those meshes mentioned in the LOD Model * Has Same CRC32 As Full Model messages?

Expand  

https://dyndolod.info/Mods/Waterfalls
For best visuals and performance typically do not install any 3rd party LOD resources - remove them if necessary.
"Any" means all, as in install none (not one) of them.

Typically the CRC32 LOD models included in DynDOLOD Resources take precedence. If there are log messages like https://dyndolod.info/Messages/LOD-Model-Has-Same-CRC32-As-Full-Model, it most likely means unnecessary files conflicting with rules that already set the full model as LOD. https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models

I will address/look into how the game engine loads things in child world cells later.

[sheson]

  On 3/29/2023 at 11:39 AM, geoffreyvanvugt said:

Ok. Right.

First, thank you for providing the correct Lod meshes. 

Thank you for quick answer. I did not know this. Learning everyday. I checked Bright Water Fix for RWT and that mod has same "lods" build for  RWT.

Checked file size with the ones from RWT and they are exactly the same. I guess they are the full models too renaming with _dyndolod_lod?

Expand  

If you mean the mod https://www.nexusmods.com/skyrimspecialedition/mods/37956, see https://dyndolod.info/Mods/Waterfalls
* Bright Waterfall Fix for ENB - do not install DynDOLOD Bright LOD Waterfall Fix

If you mean another mod not listed on that page, assume that if full models and "LOD" models have the same file size or there are log messages like https://dyndolod.info/Messages/LOD-Model-Has-Same-CRC32-As-Full-Model, that there most likely will be visual and/or performance issues.

In case of a not listed mod (or any of the mods requires updated LOD assets) make a post with a link to the mod page.

[sheson]

  On 3/29/2023 at 11:34 AM, heheloveer said:

Tested with version 122 and the large reference bugs workaround seemed to be applying when loading saves in Tamriel worldspace, since I haven't noticed any large reference bugs happening. However, full grass and grass lods can still overlap outside Whiterun with NGIO/DynDOLOD grass mode 2 and after a closer look I don't think this problem's related to the typical large reference bugs. Here's what I noticed:

1) Applying LOD Unloading Bug Fix could fix the large reference bugs in my experience (I imagine the large reference bugs workaround actively applying during the process) but it changed nothing in this case.

2) After using the tll command, I noticed there weren't many full object models outside the loaded area and upon clicking them in the console, I think these full models were all things added by the Whiterun Exterior patch, not large references. The only "large reference" I could see was the full grass.

A video to illustrate my findings: https://anonfiles.com/U0fcE3h2zb/Skyrim_Special_Edition_2023_03_29_19_10_01_mp4

Judging from this, I think there wouldn't be any overlapping if I used grass mode 1, but this is still strange. I think you once said the large reference system works in child worldspaces just like they do in parent worldspaces? Is there any other related setting or something that I'm unaware of?

Log and debug log, in case you need them: https://anonfiles.com/F6g4E1h4zf/Logs_0329_rar

Expand  

1) Object LOD not unloading in active cells after fast travel and large reference bugs are different bugs. AFAIK the LOD Unloading bug fix does not mitigates any large reference bugs. DynDOLOD dynamic LOD already fixes object LOD not unloading after fast travel, so the LOD Unloading Bug Fix is not needed.

2) Find out the coordinates of an affected cell. Check if it also happens in cells that at least a reference (added by vanilla, patch or mod), large or not.

Things go weird for cells that actually do not have LANDscape data in the child worldspace but are active inside the uGridsToLoad and have zero references. The engine fails to properly use the parent cell LAND data. There might be related issues in the area > uGridsToLoad and < uLargeRefLODGridSize.

Let me the know the answers to 2), so I can have a better idea whats up when looking into it.

[heheloveer]

  On 3/29/2023 at 12:23 PM, sheson said:

1) Object LOD not unloading in active cells after fast travel and large reference bugs are different bugs. AFAIK the LOD Unloading bug fix does not mitigates any large reference bugs. DynDOLOD dynamic LOD already fixes object LOD not unloading after fast travel, so the LOD Unloading Bug Fix is not needed.

2) Find out the coordinates of an affected cell. Check if it also happens in cells that at least a reference (added by vanilla, patch or mod), large or not.

Things go weird for cells that actually do not have LANDscape data in the child worldspace but are active inside the uGridsToLoad and have zero references. The engine fails to properly use the parent cell LAND data. There might be related issues in the area > uGridsToLoad and < uLargeRefLODGridSize.

Let me the know the answers to 2), so I can have a better idea whats up when looking into it.

Expand  

1) I know that mod isn't supposed to fix the large reference bugs, but for reasons unknown to me it did on my end. Ultimately it's not important, especially with the large reference bugs workaround applying constantly now.

2) One cell with both full grass and grass lod appearing when seen from inside the city is Cell 6,-6, Block 0,-1, SubBlock 0,-1. I don't think there's any reference of this cell under the Whiterun worldspace. As far as I can tell, outside the city, most places around clickable-in-console objects (and as a result are cells that have references under Whiterun worldspace) don't have the bug, though I can see this bug happening in Cell 3,-4, Block 0,-1, SubBlock 0,-1, which has a record in the Whiterun worldspace in both Skyrim.esm and DynDOLOD.esp. The cell in Skyrim.esm is just an empty header (not sure if this is the right word, in any case there's nothing under it) but DynDOLOD.esp added a set of glowing windows in the cell. No Landscape data for this cell, of course. I'm not sure whether similar examples exist.

[sheson]

  On 3/29/2023 at 2:00 PM, heheloveer said:

1) I know that mod isn't supposed to fix the large reference bugs, but for reasons unknown to me it did on my end. Ultimately it's not important, especially with the large reference bugs workaround applying constantly now.

2) One cell with both full grass and grass lod appearing when seen from inside the city is Cell 6,-6, Block 0,-1, SubBlock 0,-1. I don't think there's any reference of this cell under the Whiterun worldspace. As far as I can tell, outside the city, most places around clickable-in-console objects (and as a result are cells that have references under Whiterun worldspace) don't have the bug, though I can see this bug happening in Cell 3,-4, Block 0,-1, SubBlock 0,-1, which has a record in the Whiterun worldspace in both Skyrim.esm and DynDOLOD.esp. The cell in Skyrim.esm is just an empty header (not sure if this is the right word, in any case there's nothing under it) but DynDOLOD.esp added a set of glowing windows in the cell. No Landscape data for this cell, of course. I'm not sure whether similar examples exist.

Expand  

Doublecheck with the xEdit Cell finder, CTRL+ALT+F that there really is no cell record for 6,-6 in WhiterunWorld. That could explain parent world bugs in 6,-6 spilling over.

[heheloveer]

  On 3/29/2023 at 2:28 PM, sheson said:

Doublecheck with the xEdit Cell finder, CTRL+ALT+F that there really is no cell record for 6,-6 in WhiterunWorld. That could explain parent world bugs in 6,-6 spilling over.

Expand  

Thanks for the tip, and there really isn't such a cell in my load order.

[heheloveer]

The lod meshes were removed from the mod in Natural Waterfall's latest update.

[sheson]

  On 3/29/2023 at 4:12 PM, kn1ghtradiant said:

That was it, thanks! I updated the drivers which didn't help but the new .exe worked perfectly.

Expand  

Great. Can you also test this version if it still works? https://mega.nz/file/5BgHGbKT#LRe05xEQEpV4uXpZSEv6LuJaUK-g9fEvBvsnZJFYcfU

[MITSUYOMI]

hey just a quick question, upon checking the log file when running dyndolod.exe, there is a warning that indicates that a file does not adhere to file naming conventions. Does this affect the output LOD? 

[z929669]

  On 3/30/2023 at 1:10 PM, MITSUYOMI said:

hey just a quick question, upon checking the log file when running dyndolod.exe, there is a warning that indicates that a file does not adhere to file naming conventions. Does this affect the output LOD? 

Expand  

An example of this is Veydogolt Trees, and I haven't found any problems affecting the DynDOLOD outcome other than the log warnings; however, I suspect this could preclude such mods benefiting from certain DynDOLOD features now or added in the future (in addition to being bad practice in general).

That mod has bark normals named like treepineforestbarkcomp_pine_9N.dds and branch textures named like Spruce05_Normal.dds

[sheson]

  On 3/30/2023 at 1:10 PM, MITSUYOMI said:

hey just a quick question, upon checking the log file when running dyndolod.exe, there is a warning that indicates that a file does not adhere to file naming conventions. Does this affect the output LOD? 

Expand  

Read the first post which log and debug log to upload when making posts.

Read the explanations for the message https://dyndolod.info/Messages/Filename-Does-Not-Adhere-To-File-Naming-Conventions

If this affects visuals depends if the normal map texture file name is a typo or if in fact a non normal map texture has been assigned to a texture slot meant for normal map textures. If there are visuals issues, they can range from not being noticeable to being very noticeable.

Processes expect normal map textures to end in *_n.dds or vice versa filenames ending in *_n.dds to be a normal map texture.

[ysrwho]

hello, can i have some help please? Texgen suddenly stops working when creating textures. No error, no freezing, no crashing, it just stops generating. I waited for hours but it didn't continue. When it starts generating "brick012lod.dds" it just stops. I tried deleting the file from Dyndolod Resources but no solution, "brick012lod.dds" showed up and it stopped again. I'm putting texgen log below. What should i do?

TexGen 3.0 Alpha-122 x64 - Skyrim S.txtFetching info...