DynDOLOD 3.00 Alpha 169

[sheson]

15 minutes ago, PRieST said:

I know these information sites and if there are no ini changes made (it's ovious coresponding to the change log) averything is fine. I was just concerned because TexGen took 3 times longer to finish as with alpha 120.
DynDOLOD instead seemed to take longer, but in the end it was about the same time - so no issues with that.

As there is no bugreport and the run finished successful I don't think this should be looked at any further. Thank you again for the update.

A similar post was made before, so I have times from older alphas here https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-121/page/472/#comment-269642. Just for (future) reference:

TexGen 3.0 Alpha-120 x64 - Skyrim Special Edition (SSE) (28FF329B) starting session 2023-03-26 20:05:24
[01:20] TexGen completed successfully

TexGen 3.0 Alpha-121 x64 - Skyrim Special Edition (SSE) (11D61A25) starting session 2023-03-26 20:09:58
[01:18] TexGen completed successfully

[PRieST]

10 minutes ago, sheson said:

A similar post was made before, so I have times from older alphas here https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-121/page/472/#comment-269642. Just for (future) reference:

TexGen 3.0 Alpha-120 x64 - Skyrim Special Edition (SSE) (28FF329B) starting session 2023-03-26 20:05:24
[01:20] TexGen completed successfully

TexGen 3.0 Alpha-121 x64 - Skyrim Special Edition (SSE) (11D61A25) starting session 2023-03-26 20:09:58
[01:18] TexGen completed successfully

I did another few runs and this time they took about 2 minutes (as expected).
So there was something happening with the first run, but I can't tell what it was as I can't replicate the 'slow run' with 10 minutes. Maybe another background process which I haven't noticed. Whatever...I know this for the next time...first test it more than once and after that make a report.

[A_La_Derp]

On 3/22/2023 at 2:05 PM, z929669 said:

If you have assets required in your desktop path, remember that Windows has at least two shortcut links to this path (and anything under %USERPROFILE%) for backward compatibility with legacy apps. It's never a good idea to run programs from %USERPROFILE% paths or that need resources from this path. This is probably why Dyndolod is returning \C:\

Change the location of everything to a path on your C:\ drive like C:\Games or C:\Modding rather than C:\Users\. This path is also under UAC 'protection'

All your problems will likely go away then.

Thanks.

Moving all files outside of a USERPROFILE path has it working.

Much appreciated.

[sheson]

6 hours ago, A_La_Derp said:

Thanks.

Moving all files outside of a USERPROFILE path has it working.

Much appreciated.

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

[RainingTacco]

Is there a way to see which version of dyndolod i have currently installed? The changelog links me to website, but i think each dyndolod pack should have version number .txt file to see what we currently have installed. 

[sheson]

1 hour ago, RainingTacco said:

Is there a way to see which version of dyndolod i have currently installed?

Check the filename of the archive you downloaded.
Right click TexGen/DynDOLOD, exe, properties, details, file version.
Start TexGen/DynDOLOD, check window title bar.
Start TexGen/DynDOLOD, check first line of messages log.
Start TexGen/DynDOLOD, check messages logs after background loader finished for line starting with Program:

[heheloveer]

If I understand it correctly, Level 0/1/2 typically corresponds to a set of lod models named accordingly, with decreasing complexity the higher the level. So when using ultra tree lod, is there any difference between Level 0/1/2 if there's only one 3D tree lod model for each tree type?

[sheson]

46 minutes ago, heheloveer said:

If I understand it correctly, Level 0/1/2 typically corresponds to a set of lod models named accordingly, with decreasing complexity the higher the level. So when using ultra tree lod, is there any difference between Level 0/1/2 if there's only one 3D tree lod model for each tree type?

If there is no corresponding LOD model assigned to a level it should fall back to the default billboard. Howevet, LOD models without a number are assigned to Level 0/1/2, so typically it is always using the same 3D LOD model.

See the Object_Report in the log folder which assets where found and assigned.

[ToosTruus]

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.

[sheson]

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

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

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

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]

23 minutes ago, 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?

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]

12 minutes ago, 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?

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]

54 minutes ago, 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

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.