DynDOLOD 3.00 Alpha 180

[sheson]

2 hours ago, mansai said:

Thank you for your response.
I had missed your first post.

bugreport
https://ufile.io/1c33k226

DynDOLOD_SSE_log
https://ufile.io/j2a7okn1

DynDOLOD_SSE_Debug_log
https://ufile.io/4cn0fabp

Unfortunately you started DynDOLOD again after the successful generation, so the debug log got overwritten.

In regards to the CTD: I see you are using Veydogolt. The 3D LOD models are known to be bad and causing CTD. It came up before.  In particular the model with NiSwitchNode Name: `TreeAspen03`. If check teh base record as I already wrote in the other post, you will most likely find it uses a 3D tree LOD model from the mod.
I created a fixed version for another user:  https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-102/?do=findComment&comment=263935

Also pay attention to log messages:
https://dyndolod.info/Messages/Textures-Do-Not-Match - You seem to have a mod installed that overwrites DynDOLOD Resources SE imperial wall and fort LOD meshes. You might want to double overwrite orders for best visual results.
https://dyndolod.info/Messages/Deleted-Reference - There are plugins in the load order that need to be cleaned. 

[mansai]

10 hours ago, sheson said:

Unfortunately you started DynDOLOD again after the successful generation, so the debug log got overwritten.

In regards to the CTD: I see you are using Veydogolt. The 3D LOD models are known to be bad and causing CTD. It came up before.  In particular the model with NiSwitchNode Name: `TreeAspen03`. If check teh base record as I already wrote in the other post, you will most likely find it uses a 3D tree LOD model from the mod.
I created a fixed version for another user:  

 

Also pay attention to log messages:
https://dyndolod.info/Messages/Textures-Do-Not-Match - You seem to have a mod installed that overwrites DynDOLOD Resources SE imperial wall and fort LOD meshes. You might want to double overwrite orders for best visual results.
https://dyndolod.info/Messages/Deleted-Reference - There are plugins in the load order that need to be cleaned. 

We are indeed using Veydogolt Tree.
Thanks for the solution and the advice!

[Gamma_Metroid]

I have two questions regarding LOD material shaders:

1. Is it possible to configure DynDOLOD to use a different FormID for the ash and snow LOD shaders? Or would I need to use the existing vanilla forms, and modify them to be what I want?

2. Can I create a new rule for LOD shaders, for a moss LOD shader?

[sheson]

1 hour ago, Gamma_Metroid said:

I have two questions regarding LOD material shaders:

1. Is it possible to configure DynDOLOD to use a different FormID for the ash and snow LOD shaders? Or would I need to use the existing vanilla forms, and modify them to be what I want?

2. Can I create a new rule for LOD shaders, for a moss LOD shader?

This is hardcoded in the game exe. https://dyndolod.info/Help/Snow-Ash-LOD-Shader

[MisterMorden]

Hey, sheson...I'm not sure if this is the proper place to ask this but I don't have logs on it to post in the alpha support thread so sorry in advance if I messed up.  I was trying to use Blubbo's replacer (latest version) for windave's tree addon mod and every time I generated lod (newest alpha & resources fyi) I would get some tall pines that had inappropriately huge lod.  I normally wouldn't ask you about another author's mod but I noticed the author stated in the posts that you had assisted them with the mod (or maybe the scaling of the 3d lod? I might be misunderstanding) and was wondering if you might have any insight into this issue.  Thanks!

[sheson]

3 minutes ago, MisterMorden said:

Hey, sheson...I'm not sure if this is the proper place to ask this but I don't have logs on it to post in the alpha support thread so sorry in advance if I messed up.  I was trying to use Blubbo's replacer (latest version) for windave's tree addon mod and every time I generated lod (newest alpha & resources fyi) I would get some tall pines that had inappropriately huge lod.  I normally wouldn't ask you about another author's mod but I noticed the author stated in the posts that you had assisted them with the mod (or maybe the scaling of the 3d lod? I might be misunderstanding) and was wondering if you might have any insight into this issue.  Thanks!

Moved to the DynDOLOD 3 Alpha thread. As the first post explains, posts in this thread when participating in the alpha test.

Read the first post which logs and debug logs to upload when making posts. They are created when the tools are closed.

From the post, lets assume you are talking about ultra tree LOD with Level0 for LOD Level 4 and you have third party 3D tree LOD models installed that have size/scale issues.

Check ..DynDOLOD\Logs\DynDOLOD_SSE_Tree_Report.txt to see which base record uses which 3D tree LOD model.

If they are using 3D tree LOD models from Blubbos trees for Daves Trees Addon, make sure to use its latest version 1.3 which is supposed to include 3D tree LOD models I fixed.

If you are using that version and none of the 3D tree LOD models are overwritten, then provide the filename of the 3D tree LOD model in question.

[MisterMorden]

40 minutes ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread. As the first post explains, posts in this thread when participating in the alpha test.

Read the first post which logs and debug logs to upload when making posts. They are created when the tools are closed.

From the post, lets assume you are talking about ultra tree LOD with Level0 for LOD Level 4 and you have third party 3D tree LOD models installed that have size/scale issues.

Check ..DynDOLOD\Logs\DynDOLOD_SSE_Tree_Report.txt to see which base record uses which 3D tree LOD model.

If they are using 3D tree LOD models from Blubbos trees for Daves Trees Addon, make sure to use its latest version 1.3 which is supposed to include 3D tree LOD models I fixed.

If you are using that version and none of the 3D tree LOD models are overwritten, then provide the filename of the 3D tree LOD model in question.

I believe I may have found the issue just thumbing through the passthrough lod nifs...nifskope shows this one has a scale of 2.20000 TreeAddon_BlubboReachCliffTree02_19871AEEpassthru_lod.nif

All other nifs have a scale of 1.000000

[sheson]

21 minutes ago, MisterMorden said:

I believe I may have found the issue just thumbing through the passthrough lod nifs...nifskope shows this one has a scale of 2.20000 TreeAddon_BlubboReachCliffTree02_19871AEEpassthru_lod.nif

All other nifs have a scale of 1.000000

Set it to 1.0. Execute LODGen to update object LOD

[Gamma_Metroid]

1 hour ago, sheson said:

This is hardcoded in the game exe. https://dyndolod.info/Help/Snow-Ash-LOD-Shader

I see, that is unfortunate. Thanks for the info!
And just a heads up, that page in the manual says the ash forms are in Dawnguard.esm when they are actually in Dragonborn.esm.

[sheson]

2 minutes ago, Gamma_Metroid said:

I see, that is unfortunate. Thanks for the info!
And just a heads up, that page in the manual says the ash forms are in Dawnguard.esm when they are actually in Dragonborn.esm.

Of course they are. Fixed.

[Blackread]

I noticed a couple LOD related issues in my game again.

The first one is that LOD for the Winterhold College tower is flickering in and out of existence. You should see it next to the mountain on the right side.

To my eyes it looks like it could be occlusion not fully working as intended. Looking at the footage I also noticed there's something strange happening with the horizon line on the left. There's also a hole in the sea LOD that appears and disappears as you move around, this is just outside the main gate of Winterhold:

Not sure if these are related though.

The second is that there's a building in the middle of Winterhold that's not supposed the be there.

The reference 62eb6 is overwritten by The Great City of Winterhold v4.esp which makes it into a UDR, and then DynDOLOD.esm which swaps it with the fix activator. The base 9307d is last (and only) overwritten by Better Dynamic Snow SE.esp changing the directional material, as reported by console. Just as with moved large references I reported some months ago (which, as it happens, this also is), you need to approach the city from afar by foot to see the building. COCing or fast traveling straight inside it's not there.

Looking at the logs it looks like the reference for the inn is not reported as being a moved large reference, so that could be the reason for this happening.

Edited October 15, 2022 by Blackread

[sheson]

25 minutes ago, Blackread said:

I noticed a couple LOD related issues in my game again.

The first one is that LOD for the Winterhold College tower is flickering in and out of existence. You should see it next to the mountain on the right side.

To my eyes it looks like it could be occlusion not fully working as intended. Looking at the footage I also noticed there's something strange happening with the horizon line on the left. There's also a hole in the sea LOD that appears and disappears as you move around, this is just outside the main gate of Winterhold:

Not sure if these are related though.

The second is that there's a building in the middle of Winterhold that's not supposed the be there.

The reference 62eb6 is overwritten by The Great City of Winterhold v4.esp which makes it into a UDR, and then DynDOLOD.esm which swaps it with the fix activator. The base 9307d is last (and only) overwritten by Better Dynamic Snow SE.esp changing the directional material, as reported by console. Just as with moved large references I reported some months ago (which, as it happens, this also is), you need to approach the city from afar by foot to see the building. COCing or fast traveling straight inside it's not there.

Looking at the logs it looks like the reference for the inn is not reported as being a moved large reference, so that could be the reason for this happening.

Video shows wrong occlusion data. https://dyndolod.info/FAQ "Rectangular holes in LOD"
Generate occlusion for that load order. Make sure the Occlusion.esp is not being overwritten. Make sure there is no ESL flagged plugin with invalid object IDs added afterwards.

If that building is supposed to be "deleted" it should have a z of -30,000 and thus be far underground?
More Informative Console says the last plugin to change the reference is Skyrim and not DynDOLOD.esp (or The Great City of Winterhold v4.esp).

[Blackread]

1 minute ago, sheson said:

Video shows wrong occlusion data. https://dyndolod.info/FAQ "Rectangular holes in LOD"
Generate occlusion for that load order.

If that building is supposed to be "deleted" it should have a z of -30,000 and thus be far underground?

The Occlusion.esp is from the same generation as the rest of the LOD. But I noticed that I forgot to set OcclusionMaxThreadsObjectLOD to 1 when I last updated DynDOLOD, so I corrected that and regenerated occlusion, which fixed the issue.

Yes, the building would be (and is) far underground. But as I explained in my post about moved large references which used Cities of the North - Falkreath as the test setup, it doesn't matter where the large ref is moved or how the record is altered (base object swapped or anything), if the ref is moved outside the original cell, it will warp back using the last overwrite that did not move the ref outside its original cell, which in this case is Skyrim.esm. Here's my plugin for TGC Winterhold v4 if you want to test it yourself. The original has a z coordinate of around -29600 for this ref, so it probably will register as a moved large reference even if ESM flagged. Obviously I can fix this one manually by moving the ref to its original cell though.

[sheson]

7 hours ago, Blackread said:

The Occlusion.esp is from the same generation as the rest of the LOD. But I noticed that I forgot to set OcclusionMaxThreadsObjectLOD to 1 when I last updated DynDOLOD, so I corrected that and regenerated occlusion, which fixed the issue.

Yes, the building would be (and is) far underground. But as I explained in my post about moved large references which used Cities of the North - Falkreath as the test setup, it doesn't matter where the large ref is moved or how the record is altered (base object swapped or anything), if the ref is moved outside the original cell, it will warp back using the last overwrite that did not move the ref outside its original cell, which in this case is Skyrim.esm. Here's my plugin for TGC Winterhold v4 if you want to test it yourself. The original has a z coordinate of around -29600 for this ref, so it probably will register as a moved large reference even if ESM flagged. Obviously I can fix this one manually by moving the ref to its original cell though.

The number of threads to read BTO files does not change their heights or the occlusion calculations once the height data has been gathered.

An UDR should have a z of exactly -30000. Always interesting in how many ways conventions can be accidentally circumvented.

So, this test version https://mega.nz/file/NFhA0BjL#UuCNkT1WUX-yKyJMBvzonMh-SjfANS5cxlHNtK6IXZk looks at XESP opposite player only and will set the original x, y from the master and z to -30000 when it "fixes" what seems to be an UDR large reference in an ESM.

[Blackread]

5 hours ago, sheson said:

The number of threads to read BTO files does not change their heights or the occlusion calculations once the height data has been gathered.

An UDR should have a z of exactly -30000. Always interesting in how many ways conventions can be accidentally circumvented.

So, this test version https://mega.nz/file/NFhA0BjL#UuCNkT1WUX-yKyJMBvzonMh-SjfANS5cxlHNtK6IXZk looks at XESP opposite player only and will set the original x, y from the master and z to -30000 when it "fixes" what seems to be an UDR large reference in an ESM.

Thinking back on the occlusion issue, it's possible the plugins were in the wrong order, with DynDOLOD.esp overwriting Occlusion.esp. I didn't check it, so can't know for sure, but sounds like a plausible explanation to me.

Setting the original x and y coordinates works well, thank you. No rogue buildings in Winterhold anymore either.