DynDOLOD 3.00 Alpha 190

[mansai]

  On 10/12/2022 at 6:34 PM, 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. 

Expand  

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]

  On 10/15/2022 at 4:40 PM, 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?

Expand  

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]

  On 10/15/2022 at 5:56 PM, 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!

Expand  

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]

  On 10/15/2022 at 6:07 PM, 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.

Expand  

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]

  On 10/15/2022 at 6:53 PM, 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

Expand  

Set it to 1.0. Execute LODGen to update object LOD

[Gamma_Metroid]

  On 10/15/2022 at 5:42 PM, sheson said:

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

Expand  

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]

  On 10/15/2022 at 7:15 PM, 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.

Expand  

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]

  On 10/15/2022 at 9:56 PM, 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.

Expand  

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]

  On 10/15/2022 at 10:12 PM, 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?

Expand  

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]

  On 10/15/2022 at 10:28 PM, 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.

Expand  

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]

  On 10/16/2022 at 5:31 AM, 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.

Expand  

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.

[Tigornmagnus]

Hi,

I'm having a problem with the Alpha 102. TexGen runs fine, but I cant seem to get dyndolod to work.

What happens is after I start the lod generation the elapsed time on the top of the message window goes up to around 26 seconds then stops. A few more messeges/warnings appear but it doesn't seem to do anything anymore. CPU utilization is at 0% but Windows runs extremly slow while its still open. After closing the window I get a Bugreport.txt and my system returns to normal speed but there is also no output generated at all.

I tried quite a few times and it seemed to work twice, but both times after about 30 minutes Windows just froze and didn't respond anymore so I had to hit the reset button. However it generated an output those times. I can't replicate that tho.

All 3 Log files are in the attached zip file

 

Dyndolod Logs.7zFetching info...